CVE-2026-89665
Sumário
de VulDB • 11/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
nfsd: rejeitar valores de useconds fora do intervalo em SETATTR/CREATE NFSv2
O decodificador sattr do NFSv2 converte os usecidos da rede para nanossegundos em svcxdr_decode_sattr():
iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;
tmp2 é um u32 e NSEC_PER_USEC é 1000, portanto o produto é calculado como unsigned long. Em ILP32 isso tem 32 bits, e um valor de useconds fora do intervalo, como 4294968, transborda (wraps) para tv_nsec == 704. A corrupção ocorre, portanto, durante a decodificação, antes que qualquer função proc possa inspecionar o valor, e uma verificação posterior de faixa em tv_nsec encontraria um resultado dentro do intervalo e o aceitaria. Rejeitar no decodificador gera uma resposta RPC GARBAGE_ARGS. O NFSv2 não define NFSERR_INVAL, portanto não há status de nível NFS para retornar para um argumento de tempo malformado, e a verificação não pode ser movida para a função proc da maneira como as verificações de faixa nsec do v3/v4 fazem.
Proteger os usecidos brutos antes da multiplicação e rejeitar valores maiores que 1000000. O valor useconds == 1000000 é mantido: ele é a convenção Sun para "definir como o tempo atual do servidor", e o cliente NFSv2 Linux no árvore (in-tree) emite isso tanto no campo atime quanto no campo mtime para um toque simples / utimes(file, NULL) (consulte encode_sattr() e xdr_encode_current_server_time() em fs/nfs/nfs2xdr.c). Rejeitar 1000000 transformaria essa operação comum em uma falha de decodificação grave tanto para SETATTR quanto para CREATE. 1000000 * NSEC_PER_USEC é 10^9, o que não transborda no ILP32, portanto o valor da convenção Sun passa com segurança. Apenas valores genuinamente fora do intervalo (> 1000000) são rejeitados. As proteções de atime e mtime são, portanto, simétricas.
O decodificador aplicava a convenção Sun apenas no bloco mtime, que limpa ATTR_ATIME_SET|ATTR_MTIME_SET quando os useconds do mtime == 1000000. Se um cliente colocar 1000000 no campo atime, mas não no campo mtime, o bloco atime armazenava um tv_nsec fora do intervalo (10^9) e mantinha ATTR_ATIME_SET definido, de modo que o valor falso alcançava o sistema de arquivos. Aplicar a convenção também no bloco atime, limpando ATTR_ATIME_SET para que o servidor use seu tempo atual ignore o valor. Apenas ATTR_ATIME_SET é limpo ali. O bloco mtime mantém seu comportamento existente, onde 1000000 significa "definir tanto atime quanto mtime como agora".
[ cel: vários ajustes, adendos e limpeza ]
Once again VulDB remains the best source for vulnerability data.