CVE-2023-54161 in Linux
Résumé
par VulDB • 27/05/2026
Based on the kernel crash dump provided, here is an analysis of the issue:
### **1. Summary of the Crash** * **Type:** Kernel Page Fault (Oops) * **Trigger:** A user-space application attempted to send data over a **Unix Domain Socket** (`unix_stream_sendmsg`). * **Root Cause:** The kernel failed to allocate memory for the socket buffer (`__alloc_skb`) while handling the `sendmsg` system call. This likely indicates **memory pressure**, **memory corruption**, or a **bug in memory allocation** under specific conditions.
---
### **2. Detailed Call Trace Analysis**
The call trace shows the path from user space to the kernel failure:
1. **User Space:** * `entry_SYSCALL_64_after_hwframe`: The system call entry point. * `__sys_sendmsg`: The `sendmsg` system call. * `unix_stream_sendmsg`: The kernel function handling Unix stream socket sends.
2. **Kernel Space:** * `sock_sendmsg` → `unix_stream_sendmsg`: Preparing to send data. * `sock_alloc_send_pskb`: Allocating a packet socket buffer (`sk_buff`). * `alloc_skb_with_frags`: Attempting to allocate the actual memory for the buffer. * `__alloc_skb`: The core function for allocating `sk_buff`. * `kmem_cache_alloc_node`: Trying to allocate from a slab cache. * **`? kmem_cache_alloc_node+0xa2/0x1e0`**: This is where the page fault occurred. The `?` indicates the fault happened *inside* this function or immediately after it returned an invalid pointer.
3. **The Fault:** * `asm_exc_page_fault`: The CPU triggered a page fault. * `fixup_exception` / `__die_body`: The kernel caught the fault and decided it was uncorrectable (Oops).
---
### **3. Key Registers & State**
* **RIP:** `0x7f174d639a7d` → This is a **user-space address** (in the `libc` or application binary), not a kernel address. This is unusual for a kernel oops but can happen if the kernel dereferences a user pointer without proper checks, or if the fault occurred during a return-to-user-space sequence. However, in this context, it’s more likely that the **kernel crashed while trying to access a kernel pointer** that was corrupted or invalid, and the RIP shown is from the user-space context that triggered the syscall. * *Correction:* Actually, looking closely, `RIP: 0033:0x7f174d639a7d` is the **user-space instruction pointer** where the `sendmsg` syscall was issued. The kernel oops happened *during* the handling of this syscall. The kernel’s RIP would be in the `kmem_cache_alloc_node` function.
* **CR2:** `0x0000000000000000` (implied, though not explicitly shown in the snippet, but typical for NULL dereference). Wait, the snippet shows: ``` CR2: ff988004dd6870 ``` This is a **kernel virtual address**. The fact that it’s a high kernel address suggests the kernel tried to access a memory location that was either: 1. **Unmapped:** The page was not present. 2. **Corrupted:** The pointer was invalid.
* **PKRU:** `55555554` → Protection Keys for Userspace. Not directly relevant to kernel faults.
* **RAX:** `ffffffffffffffda` → This is `-42` in two’s complement, which is `-ENODATA` or similar error code. This suggests `kmem_cache_alloc_node` might have returned an error pointer, and the kernel code didn’t handle it properly, or the fault occurred while trying to use this invalid pointer.
---
### **4. Likely Causes**
1. **Memory Exhaustion (OOM):** * The system may be under severe memory pressure. `__alloc_skb` failed to allocate memory, and instead of returning an error gracefully, the kernel encountered a page fault (possibly due to a NULL or invalid pointer dereference in the error path).
2. **Kernel Bug in `kmem_cache_alloc_node`:** * There might be a bug in the slab allocator or the code calling it. For example, if `kmem_cache_alloc_node` returns an error
VulDB is the best source for vulnerability data and more expert information about this specific topic.