CVE-2026-45941

What it actually does

This is a local availability flaw in the Linux kernel TPM I2C Infineon driver. During TPM command transmission, tpm_tis_i2c_send() acquires TPM locality before calling get_burstcount(). If get_burstcount() times out and returns -EBUSY, the error path returns without releasing the acquired locality. The leaked locality can leave the TPM interface in a busy or unusable state, preventing subsequent TPM operations until the driver, device, or system is reset. The impact is denial of service to TPM-backed functionality; confidentiality and integrity are not directly affected.

Why it matters to the business

Systems that rely on a TPM may experience failures in security and availability functions such as disk-unlock workflows, measured boot, device attestation, hardware-backed key storage, certificate operations, and endpoint compliance checks. Because exploitation requires local access and the CVSS/EPSS values indicate limited current exploitation likelihood, this is lower urgency than remotely exploitable kernel bugs, but it can still disrupt production endpoints, appliances, or servers where TPM availability is operationally important.

How an attack unfolds

An attacker with local access to a system using the affected Linux kernel TPM I2C Infineon driver triggers TPM command activity through an interface such as the kernel TPM subsystem or user-accessible TPM device nodes. By repeatedly causing TPM send operations to encounter a burst-count timeout, get_burstcount() returns -EBUSY while TPM locality remains held. Once locality is leaked, later TPM transactions may fail because the TPM appears busy or unavailable. The attacker’s practical goal is not code execution but forcing TPM-dependent services and workflows to fail until recovery actions such as driver reload, device reset, or reboot occur.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the fix for the tpm_i2c_infineon locality cleanup bug. No fixed version was provided in the input, so remediation should be tracked through vendor kernel advisories and distribution changelogs for this CVE or for the upstream change that routes get_burstcount() failures through the common out_err cleanup path. Where immediate patching is not possible, reduce exposure by limiting local users and service accounts that can access TPM device nodes, reviewing membership in groups allowed to use /dev/tpm0 or /dev/tpmrm0, disabling unnecessary TPM-consuming workloads, and planning maintenance windows for systems where TPM reset or reboot would be disruptive. Avoid unloading TPM drivers on production systems unless the operational impact is understood, as doing so may interrupt security services that depend on the TPM.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the TPM I2C Infineon driver, not merely that a patched kernel is installed on disk. Check the active kernel version with uname -r, compare it to the vendor advisory or package changelog, and confirm the system has rebooted into the fixed kernel. For source-based validation, inspect the affected driver logic to ensure get_burstcount() failure exits through a cleanup path that releases TPM locality. Operationally, validate that TPM commands continue to work after repeated TPM activity and that kernel logs no longer show recurring TPM busy, timeout, or locality-related failures. If device access controls were used as mitigation, confirm permissions on /dev/tpm0 and /dev/tpmrm0 and verify only intended users or services can submit TPM commands.

Typical attack path

1. Obtain local access to a Linux system using the affected TPM I2C Infineon driver.
2. Identify that TPM device access is available, commonly through /dev/tpm0 or /dev/tpmrm0, or through a service that submits TPM commands.
3. Generate repeated TPM command activity intended to hit a burst-count timeout condition in the tpm_tis_i2c_send() path.
4. Trigger the vulnerable error path where get_burstcount() returns -EBUSY and TPM locality is not released.
5. Cause subsequent TPM operations to fail or hang because the TPM locality remains busy or unavailable.
6. Leverage the outage to disrupt disk-unlock, attestation, key-unseal, certificate, or platform-trust workflows until the system or driver is reset.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs and system journals for TPM I2C driver errors, burst-count timeouts, busy responses, or repeated TPM command failures. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, auditd records for access to TPM device nodes, endpoint telemetry showing process access to /dev/tpm0 or /dev/tpmrm0, and application logs from TPM-consuming tools or services such as attestation agents, disk-encryption unlock helpers, key-management components, and tpm2-tools. Look for a sequence in which a local process repeatedly accesses the TPM device, kernel logs show TPM timeout or busy behavior, and subsequent TPM operations fail until reboot, driver reload, or hardware reset. Because no public exploit maturity or known exploited status is indicated, these signals should be treated as suspicious availability events rather than definitive compromise without corroborating process, user, and timing evidence.

• tpm_i2c_infineon
• tpm_tis_i2c
• get_burstcount
• burstcount
• TPM locality
• locality
• -EBUSY
• Device or resource busy
• /dev/tpm0
• /dev/tpmrm0
• tpm2_
• tpm2_getrandom
• tpm2_pcrread
• tpm2_unseal
• tpm2_createprimary
• journalctl -k
• dmesg

What your security team should do

• Prioritize patching systems where TPM availability is required for boot, attestation, disk encryption, hardware-backed key storage, certificate handling, or compliance enforcement.
• Inventory Linux systems using TPM hardware and identify those that load the tpm_i2c_infineon or related TPM I2C driver modules.
• Apply vendor kernel updates and reboot into the fixed kernel during the next appropriate maintenance window.
• Until patched, restrict access to TPM device nodes and remove unnecessary users or services from TPM-access groups.
• Monitor kernel logs for TPM timeout, busy, or locality-related errors, especially repeated events followed by attestation or key-unseal failures.
• Create SOC detections for unusual repeated local access to /dev/tpm0 or /dev/tpmrm0 combined with TPM driver errors.
• Document recovery procedures for TPM unavailability, including safe service restart, driver reload if supported, device reset, or system reboot.
• Treat exploitation as a local denial-of-service event rather than a remote compromise indicator unless other evidence suggests broader intrusion.