CVE-2026-74257 in Linux
الملخص
بحسب VulDB • 15/08/2026
Based on the crash dump and stack trace provided, here is an analysis of the issue.
### **Summary** This is a **KASAN (Kernel Address Sanitizer)** report indicating a **Use-After-Free (UAF)** or potentially a **Double Free** bug in the Linux kernel networking subsystem. Specifically, it occurs within `sk_psock_verdict_apply` when handling UDP packets via eBPF socket options (`SO_ATTACH_REUSEPORT_CBPF` or similar verdict mechanisms).
The crash happens because memory allocated by `alloc_sk_msg` is accessed after being freed (or double-freed), likely due to a race condition in the packet processing path.
---
### **Detailed Analysis**
#### 1. **Crash Location & Type** - **Error:** The instruction pointer (`RIP`) points to: ```asm f0 ff ff 73 01 c3 ... ``` This is typical of a KASAN fault where the kernel tries to access memory that has been poisoned (freed). The `f0` prefix often indicates an atomic operation or lock attempt on freed memory, but in this context, it's likely part of the corrupted stack frame or register state during the UAF. - **Register State:** - `RAX: ffffffffffffffda`: This is `-26` (`ERANGE`) or a negative error code cast to unsigned long. In KASAN contexts, this often indicates an invalid pointer passed to a function (e.g., dereferencing a freed object). - The crash occurs in the context of `sk_psock_verdict_apply`.
#### 2. **Allocation Trace ("Allocated by task 6019")** The memory was allocated via: ```c alloc_sk_msg net/core/skmsg.c:510 [inline]
sk_psock_skb_ingress_self+0x60/0x350 net/core/skmsg.c:612 sk_psock_verdict_apply net/core/skmsg.c:1038 [inline]
``` - **Function:** `alloc_sk_msg` allocates a socket message structure (`struct sk_msg`). - **Context:** This is part of the eBPF "socket verdict" mechanism, where incoming packets are processed by an eBPF program attached to a UDP socket.
#### 3. **Call Path** The packet flow leading to the bug: 1. `udp_read_skb` → Reads from UDP socket. 2. `sk_psock_verdict_data_ready` → Notifies that data is ready for verdict processing. 3. `__udp_enqueue_schedule_skb` / `udp_queue_rcv_one_skb` → Queues the packet. 4. `ip_local_deliver_finish` → IP layer delivers to UDP. 5. **Critical Path:** The packet enters eBPF verdict handling via `sk_psock_verdict_apply`.
#### 4. **Root Cause Hypothesis** The most likely cause is a **race condition** in the socket message processing: - **Scenario A (Use-After-Free):** An `sk_msg` structure was freed by one thread/context while another context still holds a reference to it and tries to access or free it again. This can happen if: - The eBPF program detaches (`SO_DETACH_REUSEPORT_BPF`) while packets are being processed. - There is no proper refcounting on the `sk_msg` object during concurrent ingress/egress processing. - **Scenario B (Double Free):** Two paths attempt to free the same `sk_msg`. For example, if an error occurs in `sk_psock_verdict_apply`, it might free the message, but another part of the stack also assumes ownership and frees it later.
#### 5. **Relevant Code Areas** - **File:** `net/core/skmsg.c` - **Functions:** - `alloc_sk_msg()` (line ~510) - `sk_psock_skb_ingress_self()` (line ~612) - `sk_psock_verdict_apply()` (line ~1038)
---
### **Recommended Actions**
#### For Developers/Kernel Maintainers: 1. **Check Refcounting:** Ensure that every reference to an `sk_msg` obtained in the ingress path is properly released and not double-freed. Look for missing `kfree_skb()` or incorrect handling of `sk_psock->msg`. 2. **Race Condition Fix:** Verify synchronization between eBPF program attachment/detachment (`bpf_prog_put()`) and packet processing. If a BPF program detaches, all pending verdicts should be aborted safely without accessing freed memory. 3. **KASAN Debugging:** Enable `CONFIG_KASAN_SW_TAGS` or use hardware KASAN
If you want to get best quality of vulnerability data, you may have to visit VulDB.