CVE-2023-53857 in Linux
Riassunto
di VulDB • 15/06/2026
Based on the kernel log and the patch description provided, here is an analysis of the issue and the proposed solution.
### 1. The Problem: Lockdep Splat in BPF Local Storage
The kernel log shows a **lockdep warning** (splat) indicating that a `local_lock` is being acquired while holding a `raw_spin_lock`.
* **Why is this bad?** * In real-time (RT) kernels, `raw_spin_lock` disables preemption and interrupts. * Acquiring a `local_lock` (which may involve sleeping or complex locking logic) while holding a `raw_spin_lock` is unsafe because it can lead to deadlocks or priority inversion in RT contexts. * Specifically, the warning implies that memory allocation (`kzalloc`) is happening *after* the `raw_spin_lock` is held, which is not allowed in atomic contexts.
* **Context:** * The issue occurs in `bpf_local_storage` (specifically for **socket (`sk`) storage**). * `bpf_local_storage` uses `raw_spin_lock` to support tracing contexts where `current` task pointers are valid. * Task and cgroup local storage have already been migrated to the BPF memory allocator, which handles this safely. **Socket and inode storage have not yet been migrated.**
### 2. The Hypothetical Risk
The patch description notes that while `kzalloc(GFP_ATOMIC)` after a `raw_spin_lock` is theoretically unsafe in tracing contexts, it is **hypothetically unlikely** to cause a real bug because: * The BPF verifier ensures that the `sk` pointer passed to the helper is valid (`PTR_TO_BTF_ID`). * It is difficult to construct a scenario where a BPF program runs in a context that is both: 1. Unsafe for `kzalloc` (e.g., holding a raw spinlock in a tracing probe). 2. Has a verifier-accepted `sk` pointer.
However, to **silence the lockdep splat** and ensure correctness for RT kernels, the code must avoid any operation that might sleep or allocate memory while holding the `raw_spin_lock`.
### 3. The Solution: Move `kzalloc` Before `raw_spin_lock`
The patch modifies the code to **always perform `kzalloc` before acquiring the `raw_spin_lock`**.
#### Why this works: 1. **Before the lock:** The code is in a non-atomic context (or at least, not holding the `raw_spin_lock`), so `kzalloc` is safe. 2. **After the lock:** The code only performs operations that are safe under `raw_spin_lock` (e.g., list manipulation, reference counting). 3. **Existing behavior:** The patch notes that there was already a `kzalloc` before the lock in some paths. This change makes it consistent: **allocate first, then lock.**
### 4. Code Change Summary (Conceptual)
Before the patch: ```c raw_spin_lock(&sk->sk_lock.lock); // Hold raw_spin_lock entry = kzalloc(...); // ❌ UNSAFE: Allocation while holding lock if (!entry) {
raw_spin_unlock(&sk->sk_lock.lock); return -ENOMEM; } // ... use entry ... raw_spin_unlock(&sk->sk_lock.lock); ```
After the patch: ```c entry = kzalloc(...); // ✅ SAFE: Allocate before lock if (!entry) return -ENOMEM;
raw_spin_lock(&sk->sk_lock.lock); // Hold raw_spin_lock // ... use entry ... raw_spin_unlock(&sk->sk_lock.lock); ```
### 5. Implications
* **Lockdep Splat Fixed:** The warning about acquiring `local_lock` while holding `raw_spin_lock` will disappear because the allocation (which triggers the `local_lock` acquisition internally) now happens before the `raw_spin_lock`. * **RT Safety:** The code becomes safe for real-time kernels. * **Performance:** Minimal impact. The allocation is moved earlier, but since a lookup was likely done before, the allocation is still necessary. The critical section (holding the lock) is now shorter because it no longer includes the allocation.
### Conclusion
This patch is a **correctness fix** for real-time kernels. It ensures that memory allocation for socket local storage does not occur while holding a `raw_spin_lock`, thereby avoiding potential deadlocks and silencing lockdep warnings. It aligns the behavior of socket storage with the already-safe task/cgroup storage implementation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.