wifi: rtw88: usb: schedule rx work after everything is set up
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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.10.10, 6.6.51
- CVEs
- CVE-2024-46760
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 00:41 UTC · Revision 1
Source evidence
wifi: rtw88: usb: schedule rx work after everything is set up
core-osv · Original sourcePublished 18 Sept 2024, 07:12 UTC
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.
osv:CVE-2024-46760
Kernel
Fixed versions: 6.6.51, 6.10.10
Complete source record
{
"id": "fde09c5f592019466dbf0a6524003396603727cac1d0d4ecd99c6bff3f1ccb15",
"url": "https://osv.dev/vulnerability/CVE-2024-46760",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "wifi: rtw88: usb: schedule rx work after everything is set up",
"summary": "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.",
"evidence": "osv:CVE-2024-46760",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.51",
"evidence": "/affected/1/ranges"
},
{
"value": "6.10.10",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2024-46760",
"aliases": [
"CVE-2024-46760"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "e3037485c68ec1a299ff41160d8fedbd4abc29b9"
},
{
"fixed": "c83d464b82a8ad62ec9077637f75d73fe955635a"
},
{
"fixed": "25eaef533bf3ccc6fee5067aac16f41f280e343e"
},
{
"fixed": "adc539784c98a7cc602cbf557debfc2e7b9be8b3"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-46760.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.2.0"
},
{
"fixed": "6.6.51"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.10.10"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-46760.json"
}
}
],
"modified": "2026-10-28T02:30:45.785490611Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e",
"https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3",
"https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/46xxx/CVE-2024-46760.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-46760",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/46xxx/CVE-2024-46760.json"
}
},
"related_cves": [
{
"value": "CVE-2024-46760",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 513569,
"published_at": "2024-09-18T07:12:19.995+00:00"
}