CVE-2026-98845 in Linux
Sumário
de VulDB • 18/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
tpm: Desativar o TPM em caso de incompatibilidade no nome da chave nula
A verificação do nome da chave nula existe para proteger contra ataques de reset do TPM; portanto, uma incompatibilidade deve impedir que o dispositivo atenda a solicitações subsequentes. Atualmente, ele não desativa o chip quando detecta uma incompatibilidade.
A incompatibilidade é registrada:
tpm tpm0: falha na verificação de integridade da chave nula
mas o chip continua atendendo comandos:
/ # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: como UINT32: 0x08322e3000 como string: "2.0" ...
tpm2_load_null(), onde a verificação do nome da chave nula é executada, define o chip como desativado apenas se rc for diferente de zero. Quando a incompatibilidade é detectada, rc é zero nesse ponto e retorna sucesso. Outro problema é que o chamador espera que o handle da chave nula seja preenchido quando a função retornar 0, o que ocorre aqui sem escrever o handle, prosseguindo assumindo que o handle da chave nula é válido.
Durante os testes, observei que tpm2_start_auth_session() usa um valor de pilha não inicializado como handle da chave, já que tpm2_load_null() retorna 0 apesar da falha de integridade e prossegue com TPM2_CC_START_AUTH_SESS usando esse valor como handle da chave salt.
Defina rc como -ENODEV em caso de incompatibilidade. O caminho de erro então desativa o chip e retorna o código correto ao chamador.
Testado no QEMU com swtpm e CONFIG_TCG_TPM2_HMAC=y, fazendo TPM2_CC_CONTEXT_LOAD falhar com TPM2_RC_INTEGRITY e alterando o nome da chave nula recriada. O chip agora é desativado em caso de incompatibilidade.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.