CVE-2026-46096

What it actually does

This is a Linux kernel memory-leak vulnerability in the TPM 2.0 session handling path. The vulnerable function initializes an internal TPM buffer but fails to release it on the successful return path and on one error path involving an unrecognized hash algorithm. A local, low-privileged user who can cause repeated TPM public-read operations can force the kernel to leak page allocations over time. The primary impact is availability degradation: increasing kernel memory pressure, possible out-of-memory conditions, process termination by the OOM killer, service instability, or system crash/reboot. The flaw does not directly provide confidentiality or integrity impact and is not remotely exploitable under the published CVSS vector.

Why it matters to the business

Affected Linux systems with TPM 2.0 functionality exposed to local users may be susceptible to local denial-of-service conditions. In practical terms, a user or compromised local workload could consume kernel memory until important services fail or the host becomes unstable. Because the issue requires local access and has low EPSS, broad internet-scale exploitation is unlikely, but shared Linux servers, developer workstations, multi-user systems, CI runners, container hosts with exposed TPM interfaces, and high-availability systems should still treat it as an operational reliability risk.

How an attack unfolds

An attacker first obtains local code execution or an interactive account on a vulnerable Linux system. They then repeatedly invoke TPM functionality that reaches the kernel's TPM 2.0 public-read code path. Each affected call can allocate kernel memory without properly freeing it. By looping this operation, the attacker gradually increases unreclaimable kernel memory consumption. As memory pressure grows, the system may begin killing processes, degrading service performance, logging allocation failures, or eventually becoming unresponsive or crashing. Exploitation is expected to be noisy from an availability perspective but may not leave a unique exploit artifact beyond TPM access patterns and memory-pressure evidence.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix adding the missing tpm_buf_destroy() calls in tpm2_read_public(). No fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify the first fixed kernel for each distribution or supported kernel stream. After patching, reboot into the fixed kernel and remove or prevent booting into vulnerable kernel versions where feasible. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to TPM device nodes where operationally safe, reviewing permissions on TPM-related interfaces, isolating untrusted workloads, and monitoring for memory-pressure symptoms. Disabling TPM-related functionality may mitigate the reachable code path but should be evaluated carefully because it may affect measured boot, disk unlock, attestation, or key-management workflows.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not only the installed package version, after reboot. Compare the active kernel against the vendor advisory or changelog that contains the tpm2_read_public() buffer-destruction fix. Where source-based validation is possible, confirm that tpm2_read_public() calls tpm_buf_destroy() on both the success path and the name_size() error path. Validate exposure by checking whether TPM 2.0 support is present and whether local users or workloads can access TPM interfaces. Operationally, monitor patched systems under normal TPM use and confirm that repeated TPM public-read activity no longer results in steadily increasing unreclaimable kernel memory or OOM events.

Typical attack path

1. Gain local user-level access to a Linux system with the vulnerable kernel and TPM 2.0 support.
2. Identify that TPM device interfaces or TPM-related APIs are usable from the local context.
3. Repeatedly trigger TPM public-read operations that reach the vulnerable tpm2_read_public() code path.
4. Cause kernel page allocations to leak over repeated calls.
5. Drive cumulative kernel memory pressure until services degrade, the OOM killer terminates processes, or the host becomes unstable or crashes.

How to detect it

Because this is a local kernel memory-leak denial-of-service issue, detection should focus on evidence of repeated TPM access followed by kernel memory pressure rather than a single unique exploit signature. Review kernel logs, system journals, audit logs, endpoint telemetry, and process accounting around the time of instability. Look for repeated access to TPM device nodes, execution of TPM utilities or custom binaries, rapid growth in memory pressure, page allocation failures, OOM killer activity, service terminations, host hangs, or unexpected reboots. On systems with auditd or equivalent telemetry, search for frequent open/read/ioctl activity against TPM character devices by non-administrative users or unusual service accounts. Correlate TPM activity with kernel logs showing allocation failures or OOM events. Absence of these artifacts does not prove non-exploitation, because a memory leak may only manifest as degraded availability or a crash without preserving detailed logs.

• /dev/tpm0
• /dev/tpmrm0
• tpm2_read_public
• tpm2_readpublic
• tpm2_getcap
• tpm2-tools
• Out of memory: Killed process
• oom-killer
• page allocation failure
• Memory cgroup out of memory
• Kernel panic - not syncing

What your security team should do

• Prioritize patching on multi-user Linux systems, shared compute hosts, CI/CD runners, virtualization/container platforms, and systems where untrusted users or workloads have local execution.
• Track vendor kernel advisories and deploy the first fixed kernel available for each supported Linux distribution or appliance image; reboot to activate the fixed kernel.
• Restrict TPM device access to only users and services that require it, especially on shared systems.
• Review recent availability incidents on TPM-enabled Linux hosts for unexplained memory exhaustion, OOM killer activity, or crashes following repeated TPM activity.
• Add monitoring for kernel memory pressure, OOM killer events, and abnormal TPM device access rates until the fleet is patched.
• Where local exploitation risk is unacceptable and patching is delayed, consider temporarily disabling or limiting TPM-dependent functionality after assessing operational impact.