CVE-2024-46760 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: usb: schedule rx work after everything is set up
Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup.
The stack trace looks like this:
rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe
So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.
Fix this by moving the first usb_submit_urb after everything is set up.
For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped
[ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status
because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/06/2026
This vulnerability exists within the linux kernel's rtw88 wireless driver implementation specifically affecting the rtw8821c USB device handling. The issue stems from a race condition during the device initialization process where USB receive operations begin before the hardware object and its associated fields are fully initialized. This fundamental timing flaw creates a scenario where the rtw_rx_fill_rx_status function attempts to access hardware object fields that remain uninitialized, leading to NULL pointer dereference conditions.
The technical flaw manifests through improper sequencing of asynchronous operations during driver probe initialization. During rtw_usb_probe execution, the function calls rtw_register_hw which performs critical hardware initialization through ieee80211_register_hw and related setup routines. However, the USB receive work queue is scheduled prematurely before this complete initialization occurs, allowing rtw_usb_rx_handler to process incoming USB replies while the hw object remains in an incomplete state. This race condition creates a classic null pointer dereference scenario where rtw_rx_fill_rx_status attempts to access hw->conf.chandef.chan which remains NULL due to incomplete initialization.
The operational impact of this vulnerability extends beyond simple system crashes to potentially compromise wireless network functionality and system stability. When the NULL pointer dereference occurs, the system exhibits kernel oops messages indicating hardware configuration errors and packet dropping behavior as demonstrated in the stack trace showing the sequence from rtw_rx_fill_rx_status through rtw8821c_query_rx_desc to rtw_usb_rx_handler. This vulnerability affects the rtw_8821cu driver module and could lead to complete wireless interface failure, requiring system reboot to restore functionality.
The fix implements a straightforward but critical reordering of initialization steps by moving the first usb_submit_urb call to occur after all device setup operations complete. This ensures that rtw_register_hw and all associated initialization routines finish executing before any USB receive operations begin processing. The solution follows established best practices for asynchronous initialization patterns and prevents the race condition that leads to NULL pointer dereference. This remediation aligns with CWE-362 which addresses race conditions in concurrent programming, and addresses ATT&CK technique T1059.001 for kernel-mode exploits that leverage timing vulnerabilities. The fix ensures proper driver state management and prevents unauthorized access to uninitialized memory structures during the critical device initialization phase.