CVE-2022-48997: char: tpm: Protect tpm_pm_suspend with locks

Severity: medium (CVSS 4.7 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-10-21 · updated 2026-06-17

Description

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]

Affected products

Linux kernel: from 5.1 before 5.4.226; from 5.5 before 5.10.158; from 5.11 before 5.15.82; from 5.16 before 6.0.12; 6.1-rc1, 6.1-rc2, 6.1-rc3, 6.1-rc4, 6.1-rc5, 6.1-rc6 (+1) — fixed in 5.10.158, 5.15.82, 5.4.226, 6.0.12

How to fix

Upgrade to a fixed version: Linux kernel 5.10.158, 5.15.82, 5.4.226, 6.0.12. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2022-48997 or the next vulnerability affects your stack