CVE-2022-48997 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
char: tpm: Protect tpm_pm_suspend with locks
Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system.
Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend:
tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350
Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex.
[Jason: reworked commit message, added metadata]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/18/2026
The vulnerability described in CVE-2022-48997 resides within the Linux kernel's Trusted Platform Module (TPM) subsystem, specifically affecting the tpm_pm_suspend() function implementation. This issue represents a race condition that occurs during system suspend operations when multiple components attempt to access TPM hardware simultaneously. The flaw manifests when the hardware random number generator driver utilizes tpm_get_random() function within a kernel thread that operates independently of userspace freezing mechanisms, creating a scenario where concurrent access to TPM resources can result in system instability and potential security implications.
The technical root cause of this vulnerability stems from the absence of proper synchronization mechanisms within the tpm_pm_suspend() function. During system suspend sequences, TPM transactions execute unconditionally without proper locking mechanisms, allowing for concurrent access patterns that can corrupt TPM state information. The stack trace reveals that the error originates from tpm_tis_status.cold function with error code -52, indicating a TPM status failure where TPM_STS.x register reads invalid value 0xff, suggesting hardware state corruption during concurrent operations. This particular condition violates fundamental concurrency control principles and demonstrates a classic race condition vulnerability.
The operational impact of this vulnerability extends beyond simple system stability concerns into potential security implications for systems relying on TPM for hardware-based security functions. When multiple subsystems attempt to access TPM hardware simultaneously during suspend operations, the system may experience data corruption, transaction failures, and potentially expose the platform to attack vectors that exploit the inconsistent TPM state. The hardware random number generator component particularly amplifies this risk since it operates in a kernel thread that remains active during suspend transitions, creating a persistent access pattern that conflicts with the suspend sequence.
This vulnerability aligns with CWE-362, which specifically addresses race conditions in concurrent programming, and demonstrates characteristics consistent with ATT&CK technique T1547.001 related to system service tampering through kernel-level modifications. The fix implemented involves introducing proper locking mechanisms by calling tpm_try_get_ops() which serves as a wrapper around tpm_chip_start() and properly manages the required mutex operations to prevent concurrent access. This solution directly addresses the race condition by ensuring that TPM operations during suspend sequences are serialized through appropriate locking primitives, thereby maintaining TPM hardware integrity and preventing the corruption patterns observed in the stack trace.
The mitigation strategy specifically addresses the fundamental flaw by ensuring that all TPM access operations during system suspend are properly synchronized through the existing kernel locking mechanisms. This approach maintains the existing TPM functionality while preventing the race conditions that could lead to hardware state corruption. The implementation follows established kernel security practices by leveraging existing synchronization primitives rather than introducing new complex mechanisms that could potentially create additional vulnerabilities. System administrators should ensure their kernel versions include this patch to prevent potential system instability and maintain the integrity of TPM-based security features during suspend operations.