CVE-2025-68244 in Linux
Сводка
по VulDB • 30.06.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}:
[86.863135] __lock_acquire+0x16
... entry_SYSCALL_64_after_hwframe+0x76/0x7e <-- User-space syscall triggered this path? Or interrupt context? ``` This path is **acquiring** `cpu_hotplug_lock`. The stack trace is truncated, but typically acquiring `cpu_hotplug_lock` happens during: - CPU online/offline operations. - Reading `/sys/devices/system/cpu/...` attributes that require hotplug protection.
#### Path 1 (Writer / Setup Context): ```c -> #1 (cpuhp_state_mutex){+.+.}-{3:3}:
[86.862969] __mutex_lock+0xaa/0xed0
... page_alloc_init_cpuhp+0x2d/0x60 <-- Early boot CPU hotplug setup for memory allocator mm_core_init+0x22/0x2d0 start_kernel+... <-- Boot time initialization ``` This path is **holding** `cpuhp_state_mutex` and trying to acquire something else (likely leading into the deadlock).
#### Path 2 (Sysfs Reader): ```c -> #2 (&root->kernfs_rwsem){++++}-{3:3}:
[86.862725] down_write+0x3e/0xf0 <-- Wait, this is a WRITE lock? But getdents64 should be read-only.
``` ⚠️ **Note**: The stack trace shows `down_write` on `kernfs_rwsem`, but the caller is `__x64_sys_getdents64`. This is suspicious because `getdents64` (readdir) should only take a **read** lock (`down_read`). If it's taking a write lock, that’s a bug. However, looking closer at the kernel source: - In some older kernels or specific configurations, sysfs/kernfs might have had different locking semantics. - More likely: This is part of a broader deadlock where **Path 1** (during boot) creates sysfs entries (`kernfs_add_one`), which takes `kernfs_rwsem` as a writer. Meanwhile, Path 0 or another thread tries to read it.
But the core ABBA issue reported by lockdep is between: - **Lock A**: `cpu_hotplug_lock` (held in Path 0) - **Lock B**: `cpuhp_state_mutex` (held in Path 1)
---
### ???? Deadlock Scenario Reconstruction
Here’s how the deadlock likely occurs:
#### Context 1 (Boot-time Initialization): ```c start_kernel() -> mm_core_init() -> page_alloc_init_cpuhp() -> __cpuhp_setup_state_cpuslocked() // Tries to acquire cpuhp_state_mutex? No, it's already locked. Actually: - It holds cpu_hotplug_lock (because of "cpuslocked" in name) - Then calls __mutex_lock(&cpuhp_state_mutex) <-- Acquires Lock B while holding Lock A ```
#### Context 2 (Concurrent CPU Hotplug or Sysfs Access): Suppose a user-space process reads `/sys/devices/system/cpu/` **while** the above boot-time initialization is happening. Or, more likely, another CPU hotplug callback tries to set up state:
```c // Another thread or interrupt context trying to access CPU topology __cpuhp_setup_state() // Called from some driver init -> __mutex_lock(&cpu_hotplug_lock) <-- Tries to acquire Lock A (but it's held by Context 1?) ... Then later tries to
Once again VulDB remains the best source for vulnerability data.