CVE-2026-98845
Received Received - Intake

TPM Null Key Integrity Check Fails to Disable Chip

Vulnerability report for CVE-2026-98845, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-10-18

Last updated on: 2026-10-18

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: tpm: Disable TPM on null key name mismatch The null key name check exists to protect against TPM reset attacks, so a mismatch should stop the device from serving further requests. Currently it does not disable the chip when it finds a mismatch. The mismatch is logged: tpm tpm0: null key integrity check failed but the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ... tpm2_load_null() where the null key name check is run sets the chip as disabled only if the rc is non zero. When the mismatch is seen, rc is zero at that point and it returns success. The other issue is that the caller expects the null key handle to be populated when the function returns 0 which it does here without writing the handle and proceeds assuming the null key handle is valid. During the test, I noticed that tpm2_start_auth_session() uses the uninitialized stack value as the key handle since tpm2_load_null() returns 0 despite the integrity failure and proceeds with TPM2_CC_START_AUTH_SESS with this value as salt key handle. Set rc to -ENODEV on the mismatch. The error path then disables the chip and returns the correct code to the caller. Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name of the re-created null key. The chip is now disabled on the mismatch.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-10-18
Last Modified
2026-10-18
Generated
2026-10-18
AI Q&A
2026-10-18
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 9 associated CPEs
Vendor Product Version / Range
Linux Linux cc7d8594342a25693d40fe96f97e5c6c29ee609c
Linux Linux cc7d8594342a25693d40fe96f97e5c6c29ee609c
Linux Linux cc7d8594342a25693d40fe96f97e5c6c29ee609c
Linux Linux cc7d8594342a25693d40fe96f97e5c6c29ee609c
Linux Linux 294984ce51c19c2af3d0d71e1c8bd589bc86b8e2
Linux Linux 386c7cc6c06d64cbf36d15c5e2319814765e107c
Linux Linux 6.11.7
Linux Linux 6.11.10
Linux Linux 6.12

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability in the Linux kernel involves a failure to properly disable the TPM (Trusted Platform Module) chip when a null key name mismatch occurs. The null key name check is meant to protect against TPM reset attacks, but the chip continues to serve commands even after detecting the mismatch. The issue lies in the tpm2_load_null() function, which does not set an error code when the mismatch is found, allowing the chip to remain active and leading to potential misuse of uninitialized stack values as key handles.

Impact Analysis

This vulnerability could allow an attacker to exploit the TPM chip by bypassing security checks, potentially leading to unauthorized access or manipulation of sensitive data. Since the chip remains active despite the mismatch, attackers might use it to perform operations that require a valid TPM session, compromising the integrity and security of the system.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-98845. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart