CVE-2023-52772 in Linux
요약
\~에 의해 VulDB • 2026. 07. 03.
Based on the KASAN (Kernel Address Sanitizer) report provided, here is an analysis of the issue.
### **Summary** This is a **Use-After-Free (UAF)** bug in the Linux kernel's Unix domain socket implementation (`net/unix/af_unix.c`). Specifically, it occurs during out-of-band data handling (`queue_oob`) where an `sk_buff` (socket buffer) is freed and then accessed again.
---
### **Detailed Analysis**
#### 1. The Bug Type * **Type:** Use-After-Free (UAF). * **Component:** Unix Domain Sockets (`net/unix/af_unix.c`). * **Function Involved:** `queue_oob` is the critical function where both allocation and freeing occur, suggesting a logic error in how OOB data buffers are managed.
#### 2. Timeline of Events (Task 5295)
**Step A: Allocation** The buffer (`sk_buff`) was allocated during a send operation: ```c unix_stream_sendmsg -> queue_oob (+0xb5f/0x10a0) -> sock_alloc_send_skb -> alloc_skb ... ``` * This happens when `sendmsg()` is called with the `MSG_OOB` flag or similar OOB handling logic.
**Step B: Freeing** The same buffer was freed later in the **same function call stack**: ```c queue_oob (+0x2178 [inline])
-> consume_skb ... -> kfree_skbmem -> slab_free ... ``` * Note: The offset `+0x2178` is significantly higher than the allocation offset (`+0xb5f`) within the same function, indicating that after allocating and possibly using the buffer for OOB data, it was freed.
**Step C: Use-After-Free (The Crash)** Although the "Invalid read/write" trace is truncated in your snippet, KASAN reports typically follow this pattern: 1. **Allocated:** Buffer created at `queue_oob` offset ~0xb5f. 2. **Freed:** Buffer freed at `queue_oob` offset ~0x2178 via `consume_skb`. 3. **Used (Crash):** The buffer is accessed again after being freed, likely in a subsequent path within `unix_stream_sendmsg` or related OOB handling code that still holds a reference to the now-freed memory.
#### 3. Root Cause Hypothesis In `net/unix/af_unix.c`, the function `queue_oob()` handles out-of-band data for Unix stream sockets. The bug likely stems from: * **Double Free or Premature Free:** The buffer is freed via `consume_skb()`, but another part of the code (or a later iteration in the same logic) still tries to access it. * **Reference Counting Error:** The reference count (`sk_refcnt`) was decremented to zero, freeing the memory, but a pointer to that memory was not cleared or was reused incorrectly. * **OOB Data Handling Logic Flaw:** Unix OOB data is often queued separately. If the code allocates an `skb` for OOB data, sends it, frees it, and then later tries to peek at or process pending OOB data without properly updating pointers/queues, a UAF occurs.
---
### **Recommended Fix** 1. **Inspect `queue_oob()` in `net/unix/af_unix.c`:** * Look for places where `consume_skb(skb)` is called. * Ensure that after freeing the skb, any pointers to it (e.g., in socket state structures like `sk->sk_write_queue` or OOB-specific queues) are set to `NULL`. 2. **Check Reference Counts:** * Verify if `skb_get()` is called before passing the buffer to other functions that might outlive the current scope. 3. **Review Recent Commits:** * This type of bug often appears after changes to OOB handling or socket queue management. Check git history for recent modifications to `af_unix.c`.
### **Example Patch Direction** If the issue is that a pointer to an already-freed skb is being accessed, ensure proper nullification: ```c // In queue_oob() or related function if (skb) {
consume_skb(skb); // Ensure no dangling pointers remain if this buffer was referenced elsewhere } ```
### **How to Reproduce** * This bug is triggered by sending out-of-band data over a Unix domain socket. * A test program would: 1. Create two connected Unix sockets (`AF_UNIX`, `SOCK_STREAM`). 2
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.