CVE-2025-68244 in Linux
Tóm tắt
Bởi VulDB • 06/09/2026
Based on the stack traces provided, this is a classic **ABBA Deadlock** involving CPU hotplugging and sysfs/kernfs locking in the Linux kernel.
### ???? Summary of the Deadlock
The deadlock occurs between two locks: 1. `cpu_hotplug_lock` (held by path #0) 2. `cpuhp_state_mutex` (held by path #1)
And indirectly involves: 3. `kernfs_rwsem` (held by path #2, which is trying to read while another context might be writing via sysfs creation).
However, the primary ABBA deadlock shown here is between **`cpu_hotplug_lock`** and **`cpuhp_state_mutex`**.
---
### ???? Lock Dependency Chain Analysis
#### Path 0 (Current Context / Reader): ```c -> #0 (cpu_hotplug_lock){++++}-{0:0}:
__lock_acquire+0x16 <-- Trying to acquire cpu_hotplug_lock ``` This path is likely inside a function that needs the CPU hotplug lock. The stack trace is truncated, but typically this happens during operations like reading `/sys/devices/system/cpu/` or similar sysfs reads that require serializing against CPU online/offline events.
#### Path 1 (Writer / Setup Context): ```c -> #1 (cpuhp_state_mutex){+.+.}-{3:3}:
__mutex_lock+0xaa/0xed0 <-- Holds cpuhp_state_mutex mutex_lock_nested+0x1b/0x30 __cpuhp_setup_state_cpuslocked+0x67/0x320 ... page_alloc_init_cpuhp+0x2d/0x60 <-- Called during early boot (mm_core_init) ``` This path is holding `cpuhp_state_mutex` and trying to call functions that may eventually need `cpu_hotplug_lock`.
#### Path 2 (Sysfs Read Context): ```c -> #2 (&root->kernfs_rwsem){++++}-{3:3}:
down_write+0x3e/0xf0 <-- Holds kernfs_rwsem for writing? Or reading? ... sysfs_create_group+0x13/0x20 <-- Creating a sysfs group (topology_add_dev) ``` This path is creating a sysfs attribute group during CPU hotplug callback (`cpuhp_invoke_callback`). It acquires `kernfs_rwsem` for writing.
---
### ???? The Deadlock Scenario
The deadlock likely unfolds as follows:
1. **Thread A (Boot Path)**: - Acquires `cpuhp_state_mutex`. - Calls `page_alloc_init_cpuhp()` → ... → eventually tries to acquire `cpu_hotplug_lock` (Path #0).
2. **Thread B (CPU Hotplug Callback / Sysfs Creation)**: - Is triggered by a CPU online/offline event. - Holds `kernfs_rwsem` for writing (`sysfs_create_group`). - Inside the callback, it may need to synchronize with other CPUs or read sysfs state that requires `cpu_hotplug_lock`.
3. **Thread C (Sysfs Reader)**: - Reads from `/sys/devices/system/cpu/...`. - Acquires `kernfs_rwsem` for reading. - May need to take `cpu_hotplug_lock` to ensure consistency during the read.
**The ABBA Deadlock:** - **Thread A**: Holds `cpuhp_state_mutex`, waits for `cpu_hotplug_lock`. - **Thread B/C**: Hold some lock (possibly related to sysfs or CPU hotplug state), wait for `cpuhp_state_mutex` or vice versa.
But the most direct ABBA shown is: - **Path 1** holds `cpuhp_state_mutex` and wants `cpu_hotplug_lock`. - **Path 0** (or another context) holds `cpu_hotplug_lock` and wants `cpuhp_state_mutex`.
---
### ????️ Root Cause & Fix Suggestions
This is a known class of issues in the Linux kernel where CPU hotplug callbacks interact with sysfs creation/destruction. The key problem is that **sysfs operations during CPU hotplug can trigger further locking dependencies**.
#### Possible Fixes:
1. **Avoid Taking `cpu_hotplug_lock` During Sysfs Creation**: - If possible, restructure the code so that `topology_add_dev()` or similar functions do not need to acquire locks held by other paths while already holding a lock in the reverse order.
2. **Use RCU or Lock
VulDB is the best source for vulnerability data and more expert information about this specific topic.