Call for testing - nginx fix for "no buffer space in script copy" errors

Key points

AlmaLinux asks users to test fixed nginx packages that remove a regression introduced by the recent security update for CVE-2026-42533. After that update, nginx on some configurations randomly answers a share of requests with HTTP 500 and logs "no buffer space in script copy". The team reproduced the problem on every AlmaLinux release that received the update. The fixed packages keep the CVE-2026-42533 protection in place and are now in the AlmaLinux testing repository, waiting for feedback before they go to production.

The symptom

• After updating, affected servers log alerts like [alert] ... no buffer space in script copy in /var/log/nginx/error.log, and each alert is a request that failed with HTTP 500.
• The failures are intermittent: the same URL can work on one request and fail on the next. On one affected site, between a third and a half of the requests to a single location failed.
• It happens when a set or rewrite directive uses a variable from a map marked volatile, and the map value itself contains other variables (for example a cache key built from $scheme://$host$uri$is_args$args). Such configurations worked before the CVE update.

What went wrong

• CVE-2026-42533 is a buffer overrun in nginx's script engine, the code that builds strings from variables for set, rewrite, return and proxy_pass. The upstream fix checks the end of the result buffer before copying, and stores that buffer end in each script engine instance.
• Adding that field would change nginx's ABI and break third-party dynamic modules built against the current packages. So the backport shipped in CentOS Stream and RHEL, and therefore in AlmaLinux, keeps the buffer end in a single global variable instead.
• That only works while one script runs at a time. Scripts can be nested: a volatile map is evaluated inside the outer set, its own script overwrites the global, and the outer bounds check then compares against the wrong buffer. Whether it fails depends on where the buffers land in memory, which explains the random errors.
• Without volatile the map value is computed and cached first, so there is no nesting and no error.

What the fix does

• Every function that runs a script (ngx_http_complex_value(), ngx_http_script_run() and their stream module equivalents) now saves the global buffer end before starting and restores it when done.
• Every bounds check from the security fix is still there; a request that triggers the original overflow is still rejected with HTTP 500 and the same alert.
• The ABI does not change, so existing third-party dynamic modules keep working.
• In 2,000 requests against the example configuration, AlmaLinux counted 26 HTTP 500 errors before the fix on AlmaLinux 9 with nginx 1.20, 20 on AlmaLinux 9 with the nginx:1.24 stream and 19 on AlmaLinux 10 with nginx 1.26. With the fix, none.
• The issue and the fix were reported to Red Hat as RHEL-300689, so it can be fixed in CentOS Stream and RHEL too.

Packages in testing

• AlmaLinux 8, nginx:1.24 module stream: nginx-1.24.0-3.module_el8.10.0+4351+6f6e4e3e.5.alma.2
• AlmaLinux 9, default package: nginx-1.20.1-28.el9_8.6.alma.2
• AlmaLinux 9, nginx:1.24 module stream: nginx-1.24.0-7.module_el9.8.0+335+c30a9238.5.alma.2
• AlmaLinux 10, default package: nginx-1.26.3-6.el10_2.7.alma.1
• With a module stream, the testing repository only offers the update for the enabled stream; dnf module list nginx shows which one.

How to test

• Testing is especially welcome from anyone who has seen the alert, but "everything still works" reports count too.
• The update does not restart nginx, so restart it to load the new binary, then check the error log after a while of normal traffic.
• AlmaLinux does not recommend keeping the testing repository enabled on production machines after updating.

sudo dnf install -y almalinux-release-testing
sudo dnf upgrade 'nginx*' --enablerepo=almalinux-testing
rpm -q nginx
sudo nginx -t && sudo systemctl restart nginx
sudo grep 'no buffer space in script copy' /var/log/nginx/error.log
sudo dnf config-manager --disable almalinux-testing

Reporting results

• Results and problems go to the Development channel on AlmaLinux's Mattermost, to bugs.almalinux.org, or by email to [email protected].

Summary by DistroNews, based on the original post.