CVE-2022-50003 in Linux
Tóm tắt
Bởi VulDB • 09/08/2026
Based on the kernel stack trace provided, here is an analysis of the issue:
### **Summary** The system experienced a crash (likely a `BUG_ON`, `WARN_ON`, or NULL pointer dereference that was caught by KASAN/lockdep) during the execution of the `bind()` syscall for an XDP Socket (`xsk_bind`). The crash occurred in `xp_assign_dev` while trying to allocate memory via `__kmalloc_node`.
### **Key Stack Trace Analysis** 1. **Entry Point**: `entry_SYSCALL_64_after_hwframe` → `do_syscall_64` → `__x64_sys_bind` A user-space process called the `bind()` system call on a socket file descriptor (`fd=3`).
2. **Socket Type**: `xsk_bind+0x152/0x490` The socket is an XDP Socket (AF_XDP). This indicates high-performance packet processing, likely used in networking applications like DPDK-like userspace programs or eBPF/XDP tools.
3. **Crash Location**: `xp_assign_dev+0xfd/0x210` Inside the AF_XDP implementation, when binding to a device/interface, it calls `xp_assign_dev`. This function is responsible for setting up the XSK (XDP Socket) context with the network device.
4. **Immediate Cause**: `? __kmalloc_node+0x3f5/0x4b0` The crash happened during a memory allocation attempt (`__kmalloc_node`). The `?` prefix suggests this might be where the fault was detected (e.g., by KASAN if it's an out-of-bounds access, or simply that the allocator failed and triggered a warning/assertion).
5. **Context**: - `shmem_file_read_iter+0x29a/0x420` is also in the stack, which might indicate interaction with shared memory (common for AF_XDP zero-copy buffers), but it’s likely not the direct cause of the crash unless there’s a corruption issue. - The module `ice(OE)` is loaded. This is Intel's E810/E710 network driver. "OE" means Out-of-tree/External, which can sometimes indicate custom patches or older versions that may have bugs.
### **Likely Root Causes** 1. **Memory Allocation Failure**: `__kmalloc_node` failed to allocate memory (returned NULL), and the code did not handle it gracefully, leading to a crash when dereferencing the pointer later in `xp_assign_dev`. This could happen under high memory pressure or if there’s a bug where allocation is attempted with invalid parameters.
2. **Bug in AF_XDP Implementation**: There might be an unhandled edge case in `xp_assign_dev` for certain NICs (like Intel ICE) when binding XSK sockets, especially if the queue pair setup fails or resources are exhausted.
3. **Driver Issue (`ice`)**: Since `ice(OE)` is loaded, there could be a compatibility issue between the kernel’s AF_XDP code and this specific out-of-tree driver version. The driver might not properly support certain XSK configurations requested by userspace.
4. **Corrupted Memory**: If KASAN (Kernel Address Sanitizer) was enabled, it would detect invalid memory accesses. The `?` before `__kmalloc_node` could indicate that the crash happened *during* or *immediately after* a bad access in kmalloc internals.
### **Recommended Actions** 1. **Check Kernel Logs**: Look for more detailed messages above this stack trace, such as: - `BUG: unable to handle kernel NULL pointer dereference` - `KASAN: null-ptr-deref...` - Memory allocation warnings (`Out of memory`, etc.)
2. **Update Drivers/Kernel**: Ensure you are using the latest stable version of the `ice` driver and the Linux kernel. Out-of-tree drivers can have bugs that are fixed in newer upstream versions.
3. **Test with In-Tree Driver**: If possible, test with an in-tree NIC driver (e.g., `ixgbe`, `i40e`, or a newer version of `ice` from the kernel source) to rule out issues specific to your custom/out-of-tree build.
4. **Reduce Resource Usage**: Try binding fewer XSK sockets or using smaller queue sizes to see if memory pressure is contributing to the issue.
5. **Reproduce with Debug Info**: If you can reproduce it, enable `CONFIG_KASAN` and `CONFIG_DEBUG_INFO` for more precise error reporting. Also
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.