CVE-2026-89666
Sumário
de VulDB • 11/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
nfsd: rejeitar nseconds fora do intervalo nas operações SETATTR e create do NFSv3
Um cliente pode enviar um comando NFSv3 SETATTR, CREATE, MKDIR, SYMLINK ou MKNOD contendo um atime ou mtime cujo campo nseconds está fora do intervalo. O valor é bem-formado na rede (on the wire) e decodificado corretamente como um uint32 válido, mas não constitui um timespec64 válido: tv_nsec deve ser menor que NSEC_PER_SEC.
Nenhuma etapa no caminho setattr faz o limite desse valor. notify_change() processa a hora através de timestamp_truncate(), que não reduz tv_nsec abaixo de NSEC_PER_SEC quando o sistema de arquivos suporta granularidade em nanossegundos (s_time_gran == 1), e os setters atime/mtime do inode armazenam o valor sem alterações (apenas ctime é normalizado, via inode_set_ctime_to_ts()). O valor não normalizado corrompe então os metadados no disco: ext4's ext4_encode_extra_time() desloca tv_nsec para a esquerda por EXT4_EPOCH_BITS, o que causa um estouro do campo extra de 32 bits e danifica os bits da epoch dos segundos, fazendo com que os segundos armazenados (e consequentemente o ano) estejam incorretos ao serem lidos. XFS com bigtime armazena incorretamente a timestamp pela mesma razão.
Validar atime/mtime fornecido pelo cliente nos manipuladores de proc e retornar NFS3ERR_INVAL antes que qualquer alteração seja feita. O RFC 1813 lista NFS3ERR_INVAL para SETATTR e o descreve como o erro para um valor que o servidor 'não pode armazenar ... em sua própria representação'; o cliente mapeia isso para EINVAL.
Realizar a verificação nos manipuladores de proc, ao invés de em nfsd_setattr(), mantém a rejeição antes da criação do objeto. As operações create criam o objeto antes que nfsd_create_setattr() seja executado; portanto, uma falha tardia deixaria o novo objeto para trás e transformaria um pedido não idempotente em uma alteração no namespace que relata falha. A verificação é, portanto, feita antecipadamente nas operações de create, antes da criação do objeto.
tv_nsec é um long, então a comparação faz o cast para unsigned long (da mesma largura) ao invés de u32, correspondendo a timespec64_valid(). Um cast para u32 truncaria em sistemas de 64 bits; o cast para unsigned long também rejeita valores que se tornaram negativos quando um nseconds fora do intervalo (u32 na rede) foi atribuído a um long de 32 bits.
Apenas as times fornecidas pelo cliente são verificadas: pedidos SET_TO_SERVER_TIME não carregam valor do cliente. O sattrguard3 ctime é deliberadamente deixado inalterado: um guard fora do intervalo simplesmente nunca corresponde ao ctime do objeto e resulta em NFS3ERR_NOT_SYNC através da comparação existente de guardtime, o que é o resultado correto pelo protocolo, ao invés de rejeitar a solicitação.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.