CVE-2026-31402

Resumo

No kernel do Linux, a seguinte vulnerabilidade foi resolvida: nfsd: corrige estouro de heap no cache de replay de LOCK do NFSv4.0 O cache de replay do NFSv4.0 usa um buffer embutido fixo de 112 bytes (rp_ibuf[NFSD4_REPLAY_ISIZE]) para armazenar respostas de operações codificadas. Esse tamanho foi calculado com base em respostas de OPEN e não leva em conta respostas de negação de LOCK, que incluem o proprietário do bloqueio conflitante como um campo de comprimento variável de até 1024 bytes (NFS4_OPAQUE_LIMIT). Quando uma operação de LOCK é negada devido a um conflito com um bloqueio existente que possui um proprietário grande, nfsd4_encode_operation() copia a resposta codificada completa para o buffer de replay subdimensionado via read_bytes_from_xdr_buf() sem verificação de limites. Isso resulta em uma gravação slab-out-of-bounds de até 944 bytes além do final do buffer, corrompendo a memória heap adjacente. Isso pode ser acionado remotamente por um atacante não autenticado com dois clientes NFSv4.0 cooperativos: um define um bloqueio com uma string de proprietário grande e, em seguida, o outro solicita um bloqueio conflitante para provocar a negação. Poderíamos corrigir isso aumentando NFSD4_REPLAY_ISIZE para permitir um opaco completo, mas isso aumentaria o tamanho de cada stateowner, quando a maioria dos lockowners não é tão grande. Em vez disso, corrija isso verificando o comprimento da resposta codificada em relação a NFSD4_REPLAY_ISIZE antes de copiar para o buffer de replay. Se a resposta for grande demais, defina rp_buflen como 0 para pular o cacheamento do payload de replay. O status ainda é armazenado em cache, e o cliente já recebeu a resposta correta na solicitação original.

• CVE-2026-31402Informativo

  CVE-2026-31402