CVE-2026-68420 in Linux
Zusammenfassung
von VulDB • 10.08.2026
Based on the stack trace provided, here is an analysis of the issue:
### **Summary** This is a **kernel crash (Oops/Panic)** occurring in the Linux kernel's network subsystem. The crash happens during a `connect()` system call from user space, specifically while resolving XFRM (IPsec) security policies and templates for UDP traffic.
The key functions involved are: 1. `__sys_connect` → User-space initiating a connection. 2. `udp_connect` → Handling the connect for a UDP socket. 3. `xfrm_lookup_route` / `xfrm_resolve_and_create_bundle` → IPsec/XFRM subsystem trying to resolve security policies and create an SA (Security Association) bundle. 4. `xfrm_tmpl_resolve_one` → Resolving individual XFRM templates.
The crash likely occurs in **`ftrace_graph_ret_addr`** or a related function called from within the stack unwinding/debugging infrastructure (`__pfx_ftrace_graph_ret_addr`). This suggests either: - A bug in the kernel's ftrace/graph tracing code when handling this specific call path. - Memory corruption that corrupted the return address on the stack, causing `ftrace` to read invalid data during stack trace generation (which itself crashes).
---
### **Detailed Breakdown**
#### 1. **Trigger Point: User-space Connect** ```text [ 64.169977] __sys_connect+0xa6/0x100
[ 64.169977] udp_connect+0x43/0x50
``` A user-space application called `connect()` on a UDP socket (UDP is connectionless, but Linux allows "connecting" to set default destination). This triggers network stack processing.
#### 2. **IPsec/XFRM Policy Resolution** ```text [ 64.169977] xfrm_lookup_route+0x18/0xe0
[ 64.169977] ip4_datagram_release_cb+0x4c9/0x530
... [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310
[ 64.169977] xfrm_tmpl_resolve+0x130/0x200
[ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570
``` The system is using IPsec (XFRM). When the UDP packet needs to be sent, the kernel tries to: - Look up XFRM policies (`xfrm_lookup_route`). - Resolve security templates (`xfrm_tmpl_resolve_one`) to find or create Security Associations (SAs).
#### 3. **The Crash Location** ```text [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
[ 64.169977] ftrace_graph_ret_addr+... (implied)
``` The `?` prefix indicates this is part of a **stack trace dump** generated by the kernel's crash handler or KASAN/KCSAN/etc., not necessarily the exact instruction that faulted. However, if the crash happened *inside* `ftrace_graph_ret_addr`, it means: - The kernel was trying to unwind the stack for debugging/logging purposes. - It encountered corrupted data (e.g., invalid return addresses) on the stack or in memory.
**Most Likely Root Cause:** The actual fault is probably **earlier** in the `xfrm_tmpl_resolve_one` path, but because of how KASAN/KCSAN/ftrace works, it might have triggered a secondary crash during error reporting. Alternatively, there’s a bug in `ftrace_graph_ret_addr` when handling certain stack frames from XFRM code.
---
### **Possible Causes** 1. **Memory Corruption**: - A use-after-free or buffer overflow in the XFRM subsystem corrupted memory near the return address on the stack. - KASAN (Kernel Address Sanitizer) might have detected this, but if it’s not enabled, a plain NULL pointer dereference or invalid access could occur.
2. **Bug in `xfrm_tmpl_resolve_one`**: - This function handles complex logic for resolving IPsec templates. If there’s a race condition or null-pointer dereference here (e.g., accessing an uninitialized SA), it would crash. - The presence of `__pfx_xfrm_tmpl_resolve
If you want to get best quality of vulnerability data, you may have to visit VulDB.