CVE-2026-98845 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
tpm: Deshabilitar el TPM en caso de discrepancia con el nombre nulo de la clave
La comprobación del nombre nulo de la clave existe para proteger contra ataques de reinicio del TPM, por lo que una discrepancia debería impedir que el dispositivo siga atendiendo solicitudes. Actualmente, no desactiva el chip cuando detecta una discrepancia.
Se registra la discrepancia:
tpm tpm0: null key integrity check failed
pero el chip sigue ejecutando comandos:
/ # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ...
tpm2_load_null(), donde se ejecuta la comprobación del nombre nulo de la clave, solo deshabilita el chip si rc es distinto de cero. Cuando se detecta una discrepancia, rc es cero en ese momento y devuelve éxito (éxito). El otro problema es que el llamador espera que el identificador de la clave nula esté poblado cuando la función devuelva 0, lo cual ocurre aquí sin escribir el identificador, procediendo a asumir que el identificador de la clave nula es válido.
Durante las pruebas, observé que tpm2_start_auth_session() utiliza un valor de pila no inicializado como identificador de clave, ya que tpm2_load_null() devuelve 0 a pesar del fallo de integridad y continúa con TPM2_CC_START_AUTH_SESS utilizando este valor como el identificador de la clave sal.
Establecer rc en -ENODEV ante una discrepancia. La ruta de error deshabilita entonces el chip y devuelve el código correcto al llamador.
Probado en QEMU con swtpm y CONFIG_TCG_TPM2_HMAC=y, provocando que TPM2_CC_CONTEXT_LOAD falle con TPM2_RC_INTEGRITY y cambiando el nombre de la clave nula recreada. El chip ahora se deshabilita ante una discrepancia.
If you want to get best quality of vulnerability data, you may have to visit VulDB.