Jueves, 5 de noviembre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

AlmaLinux publica paquetes de prueba para corregir error ‘no buffer space in script copy’ en nginx

AlmaLinux ha publicado en su repositorio de testing paquetes de nginx que corrigen una regresión introducida por la actualización que solucionó CVE-2026-42533; piden pruebas de administradores que hayan observado errores HTTP 500 tras actualizar.

Por Equipo ehost3 min de lecturaFuente: Blog on AlmaLinux
AlmaLinux publica paquetes de prueba para corregir error 'no buffer space in script copy' en nginx
Imagen ilustrativa generada con inteligencia artificial.

AlmaLinux ha identificado y corregido una regresión provocada por la actualización de seguridad que abordó CVE-2026-42533 en nginx. Tras aplicar aquel parche, algunos servidores comenzaron a devolver de forma intermitente respuestas HTTP 500 y a registrar en el log entradas del tipo [alert] … no buffer space in script copy. La distribución ha preparado paquetes corregidos y los ha puesto en el repositorio de testing para que los administradores puedan verificarlos antes de su despliegue en producción.

Qué causaba el error y por qué era intermitente

El origen del problema está en el motor de scripts de nginx, responsable de construir cadenas a partir de variables en directivas como set, rewrite, return o proxy_pass. El arreglo original para CVE-2026-42533 añade una comprobación de límites antes de copiar datos al búfer de resultado; para ello se necesitó conservar la dirección final del búfer.

En las versiones empaquetadas para RHEL/CentOS Stream (y por tanto en AlmaLinux) la solución fue backportear el cambio sin modificar la interfaz binaria (ABI) de nginx: en lugar de añadir un campo por instancia del motor de scripts, la implementación guardó la dirección final del búfer en una variable global compartida. Eso funciona si solo hay un script en ejecución, pero falla cuando los scripts se anidan.

En configuraciones que usan map marcado como volatile y cuyo valor incluye otras variables, nginx evalúa la map en el momento y ejecuta un script interno que sobreescribe la variable global del extremo del búfer. Al volver al script exterior, la comprobación de límites compara contra un extremo incorrecto y, dependiendo del layout de memoria de los búferes en ese momento, la copia puede detectarse como desbordamiento y provocar un HTTP 500. Esa dependencia de la disposición de memoria explica la naturaleza intermitente del fallo.

Qué cambia con los paquetes de testing

La corrección que AlmaLinux ha compilado y publicado en testing guarda y restaura la variable global del extremo del búfer alrededor de cada ejecución de script. En la práctica, cada función que ejecuta scripts (por ejemplo, las equivalentes a ngx_http_complex_value() y ngx_http_script_run()) ahora preserva el valor anterior antes de ejecutar y lo recupera al finalizar. Con esto se consigue el mismo efecto que introducir un campo por instancia en la estructura del motor, pero sin romper la compatibilidad con módulos dinámicos de terceros.

Según las pruebas descritas por el equipo, la corrección elimina las alertas no buffer space in script copy y las fallas HTTP 500 intermitentes en las configuraciones afectadas.

Quién debe probar y qué hacer

  • AlmaLinux solicita especialmente pruebas de administradores que hayan observado las alertas no buffer space in script copy o errores HTTP 500 intermitentes tras actualizar nginx.
  • Los paquetes están en el repositorio de testing correspondiente al stream de nginx que tenga habilitado cada usuario; puede comprobarse con dnf module list nginx antes de instalar.
  • El paquete no reinicia nginx al instalarse, por lo que es necesario reiniciar o recargar el servicio para que el nuevo binario entre en funcionamiento.
  • Después de actualizar y reiniciar, se recomienda vigilar /var/log/nginx/error.log y reproducir cargas habituales para confirmar que no aparecen nuevas alertas.
  • AlmaLinux advierte no mantener el repositorio de testing habilitado en entornos de producción una vez concluida la prueba, salvo que se trate de entornos no críticos.

Cómo reportar resultados

El equipo pide que los resultados de las pruebas —tanto positivos como negativos— se comuniquen lo antes posible. Las vías disponibles son el canal de Development en su chat Mattermost, el sistema de incidencias bugs.almalinux.org o el correo del empaquetador. Además, AlmaLinux ha informado del problema y la solución a Red Hat (referencia interna RHEL-300689) para que la corrección llegue también a CentOS Stream y RHEL.

Si no ha experimentado el error, cualquier verificación que confirme que la actualización no introduce regresiones en su entorno también es útil para acelerar el pase a producción.

Lee también:

Fuente: Blog on AlmaLinux

Compartir