CVE-2025-22050

What it actually does

Missing usbnet_going_away validation in usb_submit_urb creates a race with __usbnet_queue_skb, allowing a successful URB but failed SKB queue; rx_complete then dereferences skb->next during __skb_unlink, causing NULL pointer dereference and kernel panic.

Why it matters to the business

Kernel panics on Linux systems handling USB network traffic lead to unexpected reboots, service outages, and loss of availability; widespread use of affected kernels across servers, containers, and embedded devices amplifies operational disruption.

How an attack unfolds

An attacker with local or USB-adjacent access initiates network activity over a usbnet interface; the race window between URB submission and SKB queuing is hit, causing the subsequent rx_complete path to dereference a freed or unlinked skb and trigger a panic. Similar privilege-escalation patterns appear in related kernel CVEs but this issue is a denial-of-service race.

How to fix it

Upgrade to fixed kernel versions: mainline 5.15.180 or later; Red Hat Enterprise Linux 9 packages to 5.14.0-503.14.1.el9_5 (or equivalent for bpftool, kernel-core, kernel-devel, kernel-modules, etc.). Reboot after update and verify usbnet driver loads cleanly.

How to confirm the fix worked

Confirm running kernel version matches or exceeds the listed fixed releases; exercise USB network interfaces under concurrent load while monitoring for oops or panic in dmesg; re-test after applying updates to ensure the going_away check is present in both paths.

Typical attack path

1. Attach or activate a USB network device
2. Generate RX traffic to exercise usb_submit_urb without the going_away guard
3. Win the race so SKB is not queued while URB completes
4. Trigger rx_complete → defer_bh → __skb_unlink on the dangling skb
5. Induce NULL dereference and kernel panic

How to detect it

Search kernel logs and core dumps for NULL pointer dereference or oops traces referencing usbnet, rx_complete, defer_bh, or __skb_unlink; monitor for repeated spontaneous reboots on systems with active USB network interfaces.

What your security team should do

• Prioritize kernel package updates on all affected Linux hosts and container hosts
• Restrict untrusted USB device attachment via policy or hardware controls until patched
• Enable kernel panic logging and central collection for rapid detection of usbnet-related crashes
• Review downstream dependents and rebuild any custom kernels or modules