CVE-2026-45871

What it actually does

This is a local denial-of-service flaw in the Linux kernel STMicroelectronics ST33ZP24 TPM driver. During a TPM send operation, the driver acquires a TPM locality and then calls get_burstcount(). If get_burstcount() times out and returns an error such as -EBUSY, the vulnerable code returns without releasing the previously acquired locality. That leaked TPM locality can leave the TPM device in a stuck or unavailable state, preventing subsequent TPM operations from completing. The impact is availability only; the flaw does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Systems using the affected Linux kernel driver with ST33ZP24 TPM hardware may experience TPM unavailability after a local user or process triggers the fault condition. This can disrupt services that depend on TPM-backed keys, measured boot, disk unlock workflows, attestation, device identity, or cryptographic operations. The CVSS score is moderate and EPSS is currently very low, with no known KEV listing or public exploit maturity, so broad exploitation is unlikely; however, systems where TPM availability is operationally important should still prioritize kernel updates through normal maintenance windows.

How an attack unfolds

An attacker first needs local access with the ability to issue TPM operations through the affected Linux kernel TPM interface. The attacker repeatedly triggers TPM send paths against the ST33ZP24 driver and attempts to induce a get_burstcount() timeout condition. On a vulnerable kernel, if get_burstcount() returns -EBUSY after the driver has acquired TPM locality, the function exits without cleanup. Because the locality is not released, later TPM commands may block, fail, or time out. The result is a persistent or semi-persistent TPM denial of service until the device, driver, or system is reset or the kernel is patched.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for the ST33ZP24 TPM driver cleanup path in st33zp24_send(). Because no product-specific fixed versions were provided, use the relevant Linux distribution or device vendor advisory to identify the first fixed kernel build. After patching, reboot into the updated kernel so the corrected driver is loaded. If immediate patching is not possible, reduce exposure by restricting local access, limiting permissions to TPM device nodes, disabling untrusted workloads on affected systems, and, where operationally acceptable, disabling or unloading the affected TPM driver until an update can be deployed.

How to confirm the fix worked

Confirm exposure by verifying whether the system uses ST33ZP24 TPM hardware and the st33zp24 kernel driver, then compare the running kernel package against the vendor’s fixed release. On Linux, review loaded modules, kernel configuration, TPM device presence, and distribution security advisories. After remediation, confirm the system has rebooted into the fixed kernel and that TPM operations complete normally under expected workloads. Functional validation should include checking that TPM devices are present, TPM commands succeed, and kernel logs no longer show repeated TPM timeout or busy errors during TPM activity.

Typical attack path

1. Obtain local access to a Linux system using the affected ST33ZP24 TPM driver.
2. Access the TPM interface exposed by the kernel, typically through TPM character devices or TPM-consuming software.
3. Generate TPM operations that exercise the st33zp24_send() path.
4. Cause or wait for get_burstcount() to time out and return -EBUSY.
5. Trigger the vulnerable error path where the driver returns without releasing TPM locality.
6. Leave the TPM unavailable or unreliable for subsequent operations, disrupting TPM-dependent services.

How to detect it

There are no widely reported public exploits or known threat actors associated with this issue, and exploitation may be difficult to distinguish from ordinary TPM hardware or driver instability. To check for possible prior exploitation, review kernel logs and system journals for repeated TPM timeouts, busy errors, failed TPM commands, or sudden TPM unavailability, especially following activity from local users, containers, or processes that can access TPM device nodes. Useful sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, auditd logs for access to TPM character devices, and EDR telemetry showing processes opening TPM device files. Correlate TPM errors with process execution history, user sessions, sudo activity, container starts, and access to /dev/tpm* or /dev/tpmrm*. Affected systems may show recurring TPM command failures until reboot, driver reload, or hardware reset.

• st33zp24
• get_burstcount
• -EBUSY
• TPM timeout
• tpm timeout
• tpm_tis: TPM is disabled/deactivated
• tpm tpm0: Operation Timed out
• tpm tpm0: A TPM error
• tpm tpm0: tpm_try_transmit
• /dev/tpm0
• /dev/tpmrm0
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Identify Linux systems with TPM enabled and determine whether they use ST33ZP24 TPM hardware or the st33zp24 driver.
• Prioritize patching systems where TPM availability is required for boot integrity, attestation, key protection, disk unlock, or device identity workflows.
• Update to the vendor-provided fixed kernel and reboot affected systems to ensure the patched driver is active.
• Restrict local shell, container, and workload access on affected systems until patched, especially where untrusted users can interact with TPM devices.
• Review permissions on TPM device nodes and ensure only authorized users and services can access them.
• Monitor kernel logs for TPM timeout, busy, or locality-related errors that may indicate attempted triggering or operational impact.
• If TPM becomes unavailable on an affected host, collect logs before rebooting or resetting the TPM/device so evidence is preserved.
• Track vendor advisories because fixed kernel versions may vary by distribution, hardware platform, and long-term support branch.