CVE-2023-54161 in Linux
Tóm tắt
Bởi VulDB • 21/05/2026
Based on the kernel crash dump provided, here is a detailed analysis of the issue.
### **1. Summary of the Crash** * **Type of Crash:** **Kernel Page Fault (Oops)** * **Cause:** The kernel attempted to access a memory address that was not mapped or was invalid during a system call. * **Triggering System Call:** `sendmsg` (Syscall number `0x2e` / 46). * **Context:** The crash occurred while sending data over a **Unix Domain Socket** (`unix_stream_sendmsg`).
---
### **2. Key Evidence from the Call Trace**
#### **A. The Triggering System Call** ```text RIP: 0033:0x7f174d639a7d ... ORIG_RAX: 000000000000002e <-- Syscall 46 = sendmsg ``` The user-space application called `sendmsg()`.
#### **B. The Kernel Path** The call trace shows the execution path leading to the crash: 1. `__sys_sendmsg` → `___sys_sendmsg` → `____sys_sendmsg` 2. `sock_sendmsg` → `unix_stream_sendmsg` 3. `sock_alloc_send_pskb` → `alloc_skb_with_frags` → `__alloc_skb` 4. **Crash Point:** `__alloc_skb` → `kmem_cache_alloc_node`
This indicates the kernel was trying to allocate a **SKB (Socket Buffer)** to hold the data being sent over the Unix socket.
#### **C. The Faulting Instruction** ```text ? kmem_cache_alloc_node+0xa2/0x1e0 ? __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 ``` The crash happened inside `__alloc_skb`, specifically when it tried to allocate memory from a slab cache (`kmem_cache_alloc_node`).
---
### **3. Root Cause Analysis**
#### **Most Likely Cause: Memory Corruption or Invalid Pointer** The page fault occurred in `kmem_cache_alloc_node`. This function allocates memory from a slab cache. A page fault here usually means: 1. **Corrupted Slab Cache Metadata:** The slab cache structure itself is corrupted, leading to an invalid memory access when trying to find a free object. 2. **Invalid Node Pointer:** The `node` parameter passed to `kmem_cache_alloc_node` might be invalid (e.g., a corrupted integer or pointer). 3. **Use-After-Free / Double Free:** If a previous allocation was freed incorrectly, it might have corrupted the slab allocator's internal data structures.
#### **Why Unix Socket?** Unix domain sockets are often used for local IPC. If the application is sending large amounts of data or fragmented data (`alloc_skb_with_frags`), it stresses the memory allocator. If there is a bug in the application or a driver interacting with the socket, it could corrupt kernel memory.
#### **Alternative Cause: Hardware Error** While less common, a **memory corruption due to faulty RAM** or **CPU cache issues** can also cause slab allocator corruption.
---
### **4. Recommended Debugging Steps**
#### **Step 1: Check for Memory Corruption** * **Enable Kernel Debugging Options:** * `CONFIG_SLUB_DEBUG_ON` * `CONFIG_DEBUG_SLAB` * `CONFIG_KASAN` (Kernel Address Sanitizer) – **Highly Recommended** if you can recompile the kernel. KASAN can detect use-after-free and buffer overflows. * **Check dmesg for earlier warnings:** ```bash dmesg | grep -i "slab\|kmem\|corrupt\|bug" ``` Look for warnings about slab corruption or bad pointers before the crash.
#### **Step 2: Analyze the User-Space Application** * **Check the application sending the data:** * Is it sending large messages? * Is it using `sendmsg` with `IOV_MAX` (multiple iovec structures)? * Are there any known bugs in the application that could cause buffer overflows? * **Reproduce with strace:** ```bash strace -f -e trace=sendmsg ./your_application ``` This will show the exact arguments passed to `sendmsg`, including the size and buffers.
#### **Step 3: Check for Known Kernel Bugs** * Search for bugs related to `unix_stream_sendmsg` and `kmem_cache_alloc_node` in the Linux kernel bug tracker (e.g., kernel.org, Red Hat Bugzilla, Ubuntu Launchpad). * Check if your kernel version is affected by any known slab allocator bugs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.