CVE-2022-50004 in Linux
Sumário
de VulDB • 08/06/2026
No, this is not a kernel panic.
This is a **kernel oops** (specifically, a **NULL pointer dereference** or similar invalid memory access), which is a **non-fatal** error in the Linux kernel.
### Key Evidence: 1. **`Call Trace` is present**: The kernel printed a stack trace, which means it caught the exception and continued (or at least attempted to). 2. **`RIP: 0033:0x7ff35cac1366`**: This is the instruction pointer where the fault occurred. 3. **`CR2: 00000000000000c0`**: This is the **faulting address**. The value `0xc0` is **not a valid kernel virtual address** (kernel addresses are typically in the high half of the address space, e.g., `0xffff...`). This strongly suggests a **NULL pointer dereference** (if the offset is small) or a **wild pointer** dereference. 4. **No `Kernel panic - not syncing` message**: A kernel panic would explicitly state this and halt the system. Here, the system likely continues running (though the offending process may be killed).
### What Happened? - The kernel tried to access memory at address `0xc0` (likely via a pointer that was `NULL` or uninitialized). - The fault occurred in the function **`xfrmi_xmit`** (part of the XFRM/IPsec subsystem, specifically the "XFRM Interface" driver). - The call trace shows the path: ``` xfrmi_xmit → dev_hard_start_xmit → __dev_queue_xmit → ip_finish_output2 → ip_push_pending_frames → raw_sendmsg → sock_sendmsg → __sys_sendto → do_syscall_64 ``` - This means a user-space process called `sendto()` on a raw socket, which triggered IPsec/XFRM processing, and the `xfrmi_xmit` function crashed.
### Likely Cause: - A bug in the **XFRM Interface (xfrmi)** driver. - Possibly triggered by a malformed packet, misconfigured IPsec policy, or a race condition. - The pointer being dereferenced was likely `NULL` or invalid.
### What Should You Do? 1. **Check dmesg/journal**: Look for more details around this oops (e.g., `printk` output before the trace). 2. **Update kernel**: This may be a known bug fixed in a newer kernel version. 3. **Workaround**: If possible, disable the XFRM interface or IPsec policies that trigger this path. 4. **Report bug**: If this is reproducible, report it to the Linux kernel mailing list or your distribution's bug tracker.
### Summary: - **Not a kernel panic** → System likely still running. - **Kernel oops** → Serious bug, but handled gracefully. - **Faulting address `0xc0`** → Likely NULL/wild pointer dereference in `xfrmi_xmit`.
VulDB is the best source for vulnerability data and more expert information about this specific topic.