CVE-2022-49663 in Linux
摘要
由 VulDB • 2026-06-14
Based on the kernel call trace and register dump provided, here is an analysis of the issue.
### **Summary** This is a **kernel crash (Oops/Panic)** occurring in the **`geneve_xmit`** function within the Linux kernel's GENEV (Generic Network Virtualization Encapsulation) driver. The crash was triggered by a user-space application sending a packet via a **PACKET socket** (`af_packet.c`), which was then directed to the GENEV device for transmission.
---
### **Key Components in the Call Trace**
1. **User-Space Trigger**: - `__x64_sys_sendmsg` / `packet_sendmsg`: A user-space process called `sendmsg()` on a PACKET socket. - `packet_direct_xmit`: The PACKET socket used **direct XDP (eXpress Data Path)** or similar fast-path transmission to bypass normal networking stacks.
2. **Kernel Path**: - `dev_direct_xmit` → `__dev_direct_xmit`: The packet is handed off directly to the network device's transmit queue. - `netdev_start_xmit` → `geneve_xmit`: The target device is a **GENEVE tunnel interface**. - `geneve_xmit_skb` (line 927 in `drivers/net/geneve.c`): The crash occurs here.
3. **Register State**: - `RAX: ffffffffffffffda`: This is `-22` in signed 64-bit integer, which corresponds to **`-EINVAL`** (Invalid argument). However, in the context of a crash, this might be a return value from a failed check or an error code being mishandled. - `RIP: 0x7f3baaa89109`: This is a **user-space address** (in the `libc` or application binary), not a kernel address. This suggests the crash report might be from a **user-space sanitizer** (like ASAN) or the trace was captured in a context where user-space registers were dumped alongside kernel state. However, the `Call Trace` is clearly kernel-space. - **Important**: The `RIP` in the register dump is **not** the kernel instruction pointer that caused the crash. The kernel `RIP` is implied by the last kernel function in the trace: `geneve_xmit_skb`.
---
### **Likely Cause of the Crash**
The crash occurs in `geneve_xmit_skb` at line 927. Without the exact kernel source code, we can infer common issues in this function:
1. **Invalid Packet Structure**: - The PACKET socket may have sent a malformed packet (e.g., incorrect Ethernet header, missing GENEVE header, or incorrect length). - `geneve_xmit_skb` expects a well-formed skb (socket buffer). If the packet is too short or has invalid offsets, accessing fields like `skb->data` or `skb->len` can cause an **out-of-bounds access** or **null pointer dereference**.
2. **Missing or Corrupted GENEVE Header**: - GENEVE requires a specific header. If the packet lacks this header or it is corrupted, the kernel may attempt to parse invalid memory.
3. **XDP/Direct Xmit Bug**: - Since the path goes through `packet_direct_xmit`, there might be a bug in how the PACKET socket prepares the skb for direct transmission to a GENEV device. For example, the skb might not have the correct `headroom` or `data` pointers set up properly for GENEVE encapsulation.
4. **Race Condition or Memory Corruption**: - Less likely but possible: A race condition in the GENEV device state or memory corruption elsewhere in the kernel.
---
### **How to Debug Further**
1. **Check Kernel Logs**: - Look for the actual **Oops message** or **BUG** output in `dmesg` or `/var/log/kern.log`. It will provide: - The exact instruction that faulted. - The **faulting address** (if it's a null pointer dereference or out-of-bounds access). - The **register dump** for kernel registers (RIP, RSP, RAX, etc.) at the time of the crash.
2. **Reproduce with Minimal Packet**: - Try sending a simple, well-formed GENEVE packet via PACKET socket to see if the crash is reproducible. - Use `tcpdump` or `wireshark` on the host to inspect the packet being sent.
3. **Kernel
VulDB is the best source for vulnerability data and more expert information about this specific topic.