CVE-2022-49096 in Linux
Résumé
par VulDB • 06/08/2026
Based on the crash dump provided, here is an analysis of the kernel panic/Oops.
### **Summary** This is a **NULL pointer dereference** (or invalid memory access) in the `sfc` (Solarflare network driver), specifically within the XDP (eXpress Data Path) transmission path (`efx_xdp_tx_buffers`). The crash occurs when processing an RX packet, likely triggered by malformed packets or a race condition involving XDP programs.
---
### **Key Details from Dump** 1. **Faulting Address**: `CR2: 000000000000002a` - This indicates the CPU tried to access memory at address `0x2A`. Since this is a very low virtual address, it strongly suggests dereferencing a pointer where an offset was added to a NULL base (e.g., `ptr->field`). 2. **Faulting Instruction**: ```asm Code: 48 8b 8d a8 01 00 00 ... ``` - This is likely loading from `[rbp + 0x1a8]` or similar, where `rbp` might be NULL or corrupted.
3. **Call Trace**: ```text efx_xdp_tx_buffers+0x12b/0x3d0 [sfc ...] <-- CRASH HERE
__efx_rx_packet+0x5c3/0x930 [sfc ...]
efx_rx_packet+0x28c/0x2e0 [sfc ...]
efx_ef10_ev_process+0x5f8/0xf40 [sfc ...]
? enqueue_task_fair+0x95/0x550 efx_poll+0xc4/0x360 [sfc ...]
```
---
### **Root Cause Analysis**
#### 1. **Context: XDP TX Path in RX Processing** The function `efx_xdp_tx_buffers` is called from `__efx_rx_packet`. This happens when an incoming packet triggers an XDP program that returns `XDP_TX`, causing the driver to re-transmit the same buffer out of a different queue/port.
#### 2. **Likely Bug Scenario** - The crash occurs in `efx_xdp_tx_buffers` at offset `0x12b`. - Given `CR2 = 0x2A`, it’s highly probable that: - A pointer (e.g., `tx_queue->buffer[entry]`) was NULL.
- Or, the XDP program modified packet metadata in an unexpected way, leading to invalid buffer state. - Common causes include: - **Use-after-free**: The TX queue entry was freed but still referenced by a pending XDP action. - **Race Condition**: Concurrent modification of TX descriptors without proper locking (though `sfc` usually uses per-queue locks). - **Malformed Packet/XDP Program Bug**: An eBPF program attached to the interface may have corrupted packet pointers or lengths, causing the driver to access invalid memory when trying to re-transmit.
#### 3. **Driver Version** The module hash `84c94b8e32d44d296c17e10a634d3ad454de4ba5` corresponds to a specific build of the `sfc` driver. You should check if this version has known XDP bugs or recent patches related to `efx_xdp_tx_buffers`.
---
### **Recommended Actions**
#### ✅ Immediate Mitigation 1. **Disable XDP on the Interface**: If you don’t need XDP, remove any attached eBPF programs: ```bash tc qdisc del dev <interface> clsact # Or if using bpf_prog_load directly: bpftool prog detach ... ```
2. **Update Driver/Firmware**: Check for newer versions of the `sfc` driver and Solarflare firmware. This bug may have been fixed in upstream Linux kernels or vendor drivers.
#### ???? Debugging Steps 1. **Reproduce with Minimal XDP Program**: Attach a simple "pass" or "drop" XDP program to isolate whether any eBPF code is causing corruption: ```c // Simple pass-through XDP program (C) int xdp_pass(struct xdp_md *ctx) {
return XDP_PASS; } ```
2. **Check Kernel Logs**: Look for earlier warnings in `dmesg`
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.