CVE-2025-23149 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
tpm: do not start chip while suspended
Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call:
[35985.503771] i2c i2c-1: Transfer while suspended
[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810
[35985.503802] Modules linked in:
[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f
[35985.503814] Tainted: [W]=WARN
[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810
[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5
[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246
[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000
[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001
[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820
[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120
[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000
[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0
[35985.503855] Call Trace:
[35985.503859] <TASK>
[35985.503863] ? __warn+0xd4/0x260
[35985.503868] ? __i2c_transfer+0xbe/0x810
[35985.503874] ? report_bug+0xf3/0x210
[35985.503882] ? handle_bug+0x63/0xb0
[35985.503887] ? exc_invalid_op+0x16/0x50
[35985.503892] ? asm_exc_invalid_op+0x16/0x20
[35985.503904] ? __i2c_transfer+0xbe/0x810
[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0
[35985.503920] tpm_cr50_i2c_read+0x8e/0x120
[35985.503928] tpm_cr50_request_locality+0x75/0x170
[35985.503935] tpm_chip_start+0x116/0x160
[35985.503942] tpm_try_get_ops+0x57/0x90
[35985.503948] tpm_find_get_ops+0x26/0xd0
[35985.503955] tpm_get_random+0x2d/0x80
Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/15/2026
The vulnerability described in CVE-2025-23149 resides within the Linux kernel's Trusted Platform Module (TPM) subsystem, specifically in how the system handles chip state management during suspension events. This flaw manifests when the kernel attempts to start a TPM chip while it is already in a suspended state, leading to unintended operations that can result in system instability or potential security breaches. The issue is particularly concerning because it involves a critical security component designed to protect against hardware-level attacks and maintain cryptographic integrity.
The technical root cause of this vulnerability lies in the improper sequencing of operations within the TPM chip initialization and state checking logic. When tpm_find_get_ops() is called to retrieve the appropriate operations for a TPM chip, the system checks for the TPM_CHIP_FLAG_SUSPENDED flag after this function call, rather than before. This ordering flaw allows a spurious tpm_chip_start() function call to occur even when the chip is suspended, causing a transfer operation to proceed on a suspended device. This mismanagement results in kernel warnings and potential system crashes, as evidenced by the stack trace showing the sequence of function calls leading to __i2c_transfer being invoked on a suspended I2C bus.
The operational impact of this vulnerability extends beyond simple system instability to potential security implications within the Trusted Computing Base. When a TPM chip is suspended, it should remain in a quiescent state to prevent unauthorized access or manipulation of cryptographic operations. The improper handling of this suspension state could allow malicious actors to exploit timing or state inconsistencies to gain unauthorized access to TPM-protected data or disrupt cryptographic processes that depend on TPM functionality. This vulnerability directly affects systems using TPM chips over I2C interfaces, particularly those with CR50 TPM implementations, where the tpm_cr50_i2c_transfer_message function is involved in the problematic execution path.
Mitigation strategies for this vulnerability involve implementing proper state checking before attempting to start TPM chip operations. The fix ensures that tpm_try_get_ops() does not proceed with tpm_chip_start() if the TPM_CHIP_FLAG_SUSPENDED flag is set, thereby preventing operations on suspended devices. This aligns with common security practices outlined in the CWE catalog, specifically CWE-691, which addresses insufficient control over potentially dangerous operations. The solution also reflects principles from the MITRE ATT&CK framework, particularly in the area of privilege escalation and system resource manipulation, where unauthorized access to hardware components could be leveraged for further exploitation. Users should update their kernel versions to include the patched code that enforces proper state management and prevents the erroneous chip start operations during suspension states.
The vulnerability demonstrates a classic example of race condition and state management issues in kernel-level code, where timing-sensitive operations must maintain strict consistency between hardware state and software operations. The error message "Transfer while suspended" and the associated kernel oops indicate that the system attempted to perform I2C operations on a device that was explicitly marked as suspended, violating fundamental assumptions about device state management. This flaw underscores the importance of proper synchronization and state validation in security-critical kernel subsystems, where incorrect assumptions about device states can lead to both operational failures and potential security weaknesses.