CVE-2025-21649 in Linux
Resumen
por VulDB • 2026-06-09
Based on the stack trace provided, here is an analysis of the issue:
### **Summary** This is a **kernel panic/oops** occurring in the **Open vSwitch (OVS)** kernel module (`openvswitch.ko`) on an **ARM64** Linux system. The crash happens while OVS is trying to send a packet out through an internal virtual port, which then triggers a network transmission path that ultimately fails.
---
### **Key Observations from the Stack Trace**
1. **Crash Context**: - The crash occurs in `dev_hard_start_xmit` (the low-level network device transmit function). - This is called recursively: - First, OVS sends a packet via `ovs_vport_send` → `do_output` → `ovs_execute_actions` → `ovs_dp_process_packet` → `ovs_vport_receive` → `internal_dev_xmit`. - Then, the internal device (`internal_dev_xmit`) calls `dev_hard_start_xmit` again, which eventually leads to `ip_finish_output2` → `udp_sendmsg` → `__sys_sendto`. - The second `dev_hard_start_xmit` call (at `[128.410600]`) is where the crash likely occurs.
2. **Open vSwitch Involvement**: - The stack shows heavy involvement of OVS: - `ovs_vport_send` - `do_output` - `do_execute_actions` - `ovs_execute_actions` - `ovs_dp_process_packet` - `ovs_vport_receive` - `internal_dev_xmit` - This suggests the crash happens while OVS is processing a packet and attempting to forward it through an internal port (likely a `dpdk` or `internal` vport).
3. **Network Stack Path**: - The packet is being sent via UDP (`udp_sendmsg`), which implies the packet is an IP/UDP packet being transmitted. - The path goes through `ip_finish_output2` → `__ip_finish_output` → `ip_finish_output` → `ip_output` → `ip_send_skb` → `udp_send_skb`.
4. **ARM64 Architecture**: - The stack ends with `el0_sync` and `el0_sync_handler`, indicating an exception occurred in user space or kernel space on an ARM64 CPU.
---
### **Likely Causes**
1. **Bug in Open vSwitch Kernel Module**: - A known bug in the `openvswitch` kernel module, especially when using internal ports or DPDK. - Possible issues: - Null pointer dereference in `internal_dev_xmit`. - Race condition in packet processing. - Memory corruption in OVS datapath.
2. **Driver Issue**: - The underlying network driver (e.g., for the internal port or DPDK interface) may have a bug in its `hard_start_xmit` implementation.
3. **Packet Corruption**: - A malformed packet may cause the kernel to crash when processing it in `ip_finish_output2` or `udp_send_skb`.
4. **Resource Exhaustion**: - Out of memory, socket buffer exhaustion, or other resource limits may lead to a crash in the transmit path.
---
### **Debugging Steps**
1. **Check Kernel Logs**: - Look for additional messages before the crash: ```bash dmesg | tail -n 50 ``` - Look for warnings about OVS, DPDK, or network drivers.
2. **Enable OVS Debugging**: - Enable OVS debugging in the kernel: ```bash echo 1 > /sys/module/openvswitch/parameters/debug ``` - Check `dmesg` for OVS-specific logs.
3. **Check for Known Bugs**: - Search for known issues with your version of Open vSwitch and kernel: - [Open vSwitch Bug Tracker](https://bugzilla.openvswitch.org/)
- Kernel bug reports related to `dev_hard_start_xmit` and OVS.
4. **Update Software**: - Update Open vSwitch and the kernel to the latest stable versions. - If using DPDK, ensure the DPDK version is compatible with your kernel and OVS version.
5. **Reproduce the Issue**: - Try to reproduce the crash with a minimal test case: - Create a simple OVS bridge with an internal port. - Send UDP packets through the bridge. - Monitor for crashes.
6. **Check for Memory Issues**: - Use `kmemleak
If you want to get best quality of vulnerability data, you may have to visit VulDB.