Como o Erro nginx no buffer space Afeta Rewrites

Atualizar o nginx para fechar a CVE-2026-42533 passou a devolver HTTP 500 em parte das requisições, com o alerta nginx no buffer space in script copy registrado no error.log. O erro é intermitente e aparece em configurações que usam map com volatile alimentando set ou rewrite.

O que o erro nginx no buffer space significa

Cada alerta desses no /var/log/nginx/error.log equivale a uma requisição que morreu com HTTP 500. A mesma URL funciona em uma chamada e falha na seguinte, o que costuma mandar o diagnóstico para o lado errado do problema.

[alert] 12345#0: *678 no buffer space in script copy, client: 192.0.2.10, server: example.com, request: "GET /some/path HTTP/1.1"

O gatilho é específico: diretivas set ou rewrite que consomem uma variável de map marcado volatile, e esse valor de map contém outras variáveis. Um map $uri $cache_key com default "$scheme://$host$uri$is_args$args" e um set $key $cache_key em algum location já basta. Antes da atualização de segurança, essas configurações funcionavam.

Por que só quebra com map volatile

A CVE-2026-42533 é um buffer overrun no motor de script do nginx, o código que monta strings a partir de variáveis para set, rewrite, return e proxy_pass. O commit upstream resolve isso guardando o fim do buffer em cada instância do motor e checando os limites antes de copiar.

Guardar o campo na struct muda a ABI do nginx e quebra módulos dinâmicos de terceiros compilados contra os pacotes atuais. Para evitar isso, o backport que foi para CentOS Stream e RHEL, e por consequência para o AlmaLinux, manteve o fim do buffer em uma variável global. Funciona enquanto apenas um script roda por vez.

Scripts aninham. Ao copiar o valor de um map volatile, o nginx avalia o map naquele instante e roda o script interno que monta "$scheme://$host$uri...". Esse script interno sobrescreve a variável global com o fim do buffer dele, e o set externo passa a comparar contra o buffer errado. Se a checagem falha depende de onde os dois buffers caíram na memória, daí a aleatoriedade. Sem volatile, o valor é calculado e cacheado antes, sem aninhamento.

O que o patch em teste muda

A correção é pequena: cada função que executa script, incluindo ngx_http_complex_value(), ngx_http_script_run() e os equivalentes do módulo stream, salva o fim de buffer global antes de começar e restaura ao terminar. O script interno continua usando a global, mas o externo recupera o valor correto na volta.

A proteção da CVE-2026-42533 permanece, com todas as checagens de limite no lugar e apontando para o buffer certo. A ABI não muda, então módulos de terceiros seguem carregando. Em 2000 requisições contra a configuração de exemplo, os pacotes anteriores devolveram 26 erros 500 no AlmaLinux 9 com nginx 1.20, 20 no stream nginx:1.24 do AlmaLinux 9 e 19 no AlmaLinux 10 com nginx 1.26. Com o patch, zero nos três casos.

O problema foi reportado à Red Hat como RHEL-300689, para correção em CentOS Stream e RHEL. Quem roda derivados do RHEL 8, 9 ou 10, inclusive imagens de contêiner construídas sobre esses repositórios, herda o backport. Debian e Ubuntu seguem o código upstream e têm outro caminho de empacotamento.

Pacotes em teste e verificação

Os pacotes corrigidos estão no repositório de testes do AlmaLinux, com versões como nginx-1.20.1-28.el9_8.6.alma.2 no AlmaLinux 9 e nginx-1.26.3-6.el10_2.7.alma.1 no AlmaLinux 10. Em stream de módulo, o repositório de teste só oferece a atualização do stream habilitado, verificável com dnf module list nginx.

O teste pede habilitar almalinux-release-testing, subir nginx* com --enablerepo=almalinux-testing, conferir com rpm -q nginx e reiniciar o serviço, já que a atualização não reinicia sozinha. Depois de rodar com tráfego normal, um grep 'no buffer space in script copy' /var/log/nginx/error.log não deve achar alertas novos. Relatos de falha e de sucesso vão para o canal Development no Mattermost ou para o bugs.almalinux.org.

Conclusão

A regressão do nginx no buffer space vem de um backport que trocou o campo por instância por uma global, e só aparece quando scripts aninham via map volatile. Até o patch sair da fase de teste, vale revisar onde o volatile é realmente necessário no seu nginx.conf e acompanhar o relatório na Red Hat.

Fonte: https://almalinux.org/blog/2026-11-04-nginx-script-copy-fix-call-for-testing/