CVE-2022-50004 in Linux
सारांश
द्वारा VulDB • 09/06/2026
Linux kernel panic/crash analysis based on the provided call trace.
### **1. Summary** - **Crash Type**: Kernel Oops/Panic due to a **NULL pointer dereference** or invalid memory access. - **Faulting Address**: `CR2: 00000000000000c0` (192 bytes from NULL). - **Triggering Function**: `xfrmi_xmit` (XFRM Interface transmit). - **Context**: Sending a raw IP packet (`raw_sendmsg`) via a socket. - **Module Involved**: `xfrm_user`/`xfrm_interface` (XFRM is part of IPsec).
---
### **2. Detailed Analysis**
#### **A. Faulting Address (`CR2`)** - `CR2: 00000000000000c0` indicates the CPU tried to access memory at virtual address `0xc0`. - This is **not** a valid kernel address. It suggests the code dereferenced a pointer that was either: - `NULL` (0x00) + offset (0xc0). - A corrupted/uninitialized pointer.
#### **B. Call Trace Breakdown** The crash occurred in the network transmit path:
1. **`xfrmi_xmit+0xde/0x460`** - **Root Cause**: The crash happened here. `xfrmi_xmit` is the transmit function for **XFRM Interface** (virtual interface for IPsec). - The offset `0xde` suggests the fault occurred early in the function, likely when accessing a member of a structure (e.g., `skb->dst`, `dev->priv`, or `xfrm_state`).
2. **`dev_hard_start_xmit`** - Standard Linux network stack function that calls the device’s `hard_start_xmit` callback (`xfrmi_xmit`).
3. **`__dev_queue_xmit` → `ip_finish_output2` → `ip_push_pending_frames`** - The kernel was preparing to send an IP packet.
4. **`raw_sendmsg`** - A user-space application called `sendto()` on a **raw socket** (`AF_INET`, `SOCK_RAW`). - This is unusual for IPsec traffic, which typically uses `PF_KEY` or `NETLINK` for control and `AF_XDP`/`AF_PACKET` for data. However, raw sockets can trigger IPsec policies if configured.
5. **`sock_sendmsg` → `__sys_sendto` → `do_syscall_64`** - User-space system call entry.
---
### **3. Likely Causes**
#### **1. Missing or Invalid `dst` Entry** - In `xfrmi_xmit`, the kernel expects a valid `dst` (destination cache) entry attached to the `skb`. - If `skb->dst` is `NULL` or corrupted, accessing `skb->dst->...` at offset `0xc0` could cause this crash. - **Why?** Raw sockets may not always attach a proper `dst` entry, especially if routing/IPsec policies are misconfigured.
#### **2. XFRM State Misconfiguration** - If an IPsec policy is applied to the raw socket’s traffic, the kernel tries to encrypt the packet via `xfrmi_xmit`. - If the corresponding `xfrm_state` is not properly initialized or is being freed concurrently, dereferencing it could crash.
#### **3. Race Condition** - If the XFRM interface or associated state is being deleted while a packet is being transmitted, a use-after-free or NULL dereference can occur.
#### **4. Kernel Bug in `xfrmi_xmit`** - This could be a bug in the Linux kernel’s XFRM interface code, especially if: - The kernel version is outdated. - A recent patch introduced a regression.
---
### **4. Recommendations**
#### **Immediate Workarounds** 1. **Avoid Raw Sockets with IPsec Policies** - If you are using raw sockets, ensure no IPsec policies are applied to the traffic. - Check `ip xfrm policy` and `ip xfrm state` for rules that might affect raw socket traffic.
2. **Disable XFRM Interface for Testing** - If the crash is reproducible, try removing the XFRM interface: ```bash ip link del xfrmi0 # Replace with your interface name ```
3. **Update Kernel** - This issue may have been fixed in newer kernel versions. Check
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.