CVE-2024-35795 in Linux
Résumé
par VulDB • 26/05/2026
Based on the kernel log provided, this is a **deadlock detection report** (likely from `lockdep`) in the Linux kernel, specifically involving the **AMDGPU driver**.
### ???? Summary of the Issue A **deadlock** was detected between two locks: 1. `reservation_ww_class_mutex` (held by the current thread) 2. `&mm->mmap_lock` (attempted to be acquired by the current thread, but another CPU holds it in a conflicting order)
The deadlock occurs in the function `amdgpu_debugfs_mqd_read`, which is called when reading debugfs files related to AMDGPU MQD (Memory Queue Descriptor).
---
### ???? Key Details from the Log
#### 1. **Lock Chain Causing Deadlock** ``` Chain exists of: &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex ``` This means: - **CPU0** holds `reservation_ww_class_mutex` and tries to acquire `&mm->mmap_lock`. - **CPU1** holds `&mm->mmap_lock` and tries to acquire `reservation_ww_class_mutex` (via `reservation_ww_class_acquire`).
This is a classic **ABBA deadlock** (lock inversion).
#### 2. **Stack Trace (Current Thread T1082)** ``` amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]
-> calls __might_fault -> tries to acquire &mm->mmap_lock ``` The function `amdgpu_debugfs_mqd_read` is reading debugfs data, which may involve accessing user-space memory or faulting into page tables. This triggers `__might_fault`, which tries to take `mmap_lock` for safety.
However, the thread **already holds** `reservation_ww_class_mutex` (acquired earlier in `amdgpu_debugfs_mqd_read`), leading to the circular dependency.
#### 3. **Lock Held by Current Thread** ``` 1 lock held by tar/1082: #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]
```
---
### ????️ Root Cause The AMDGPU debugfs code (`amdgpu_debugfs_mqd_read`) is: 1. Acquiring `reservation_ww_class_mutex` to safely access GPU reservation objects. 2. Then attempting to read data that may involve user-space memory access, which triggers `__might_fault`. 3. `__might_fault` tries to acquire `mmap_lock` to prevent races during page faults. 4. But `mmap_lock` is already held by another thread that is trying to acquire `reservation_ww_class_mutex` (or a related lock), causing a deadlock.
This is a **lock ordering violation** in the AMDGPU driver.
---
### ✅ Potential Fixes
#### 1. **Avoid Taking `mmap_lock` in Debugfs Read Path** If the data being read does not actually involve user-space memory that can fault, avoid calling functions that might fault. For example: - Use `copy_to_user()` carefully, ensuring no page faults occur. - Pre-allocate or use kernel-space buffers instead of accessing user-space directly.
#### 2. **Reorder Lock Acquisition** Ensure that `reservation_ww_class_mutex` is **not held** when calling code that might take `mmap_lock`. For example: - Release `reservation_ww_class_mutex` before reading data that might fault. - Re-acquire it afterward if needed.
#### 3. **Use `might_fault()` Instead of Implicit Fault Handling** If the code path is known to be safe from faults, use `might_fault()` to annotate it, or ensure that `__might_fault` is not triggered unnecessarily.
#### 4. **Patch the AMDGPU Driver** This is likely a known issue in older kernels. Check if there is an upstream fix in newer kernel versions. The fix typically involves: - Restructuring `amdgpu_debugfs_mqd_read` to avoid holding `reservation_ww_class_mutex` during memory access. - Using `dma_resv_lock()` with proper nesting rules.
---
### ???? References - **Lockdep documentation**: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html - **AMDGPU driver source**: `drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c` - **mmap_lock documentation**: https://www.kernel.org/doc/html/latest/core-api/mm_api
VulDB is the best source for vulnerability data and more expert information about this specific topic.