CVE-2026-80943

What it actually does

An out-of-bounds index in the Linux kernel Realtek rtl8192du (rtlwifi) transmit path uses the 802.11 QoS TID from ieee80211_get_tid() (range 0–15) to index sta_entry->tids[], which is only MAX_TID_COUNT (9) elements. A TID greater than 8 therefore reads or writes past the aggregation-state array inside rtl92du_tx_fill_desc(), producing kernel memory corruption that can panic the host and may disturb adjacent kernel state (limited confidentiality and integrity impact, high availability impact).

Why it matters to the business

Linux laptops, embedded, and IoT systems using an RTL8192DU wireless adapter can be crashed or forced to reboot by an unauthenticated attacker who is already on the same Wi-Fi or in RF range, causing sudden loss of network and possibly the whole machine until reboot. Impact is primarily downtime rather than data theft. Exploitation likelihood is currently low: EPSS is about 0.37% and flat over 30 days, the issue is not in CISA KEV, ransomware use is not reported, and public exploit maturity is none. The CVE is roughly 20 days old; treat it as a standard high-severity kernel memory-safety patch, not an emergency KEV-driven outage, unless these chipsets are widely deployed on untrusted wireless networks.

How an attack unfolds

An attacker with adjacent-network access (same wireless LAN or RF proximity) causes the rtl8192du driver to transmit or fill a descriptor for an 802.11 QoS frame whose TID is outside the 0–8 range the driver allocates. rtl92du_tx_fill_desc() takes that 4-bit TID and uses it as an array index into a 9-element tids table, accessing kernel memory past the aggregation-state array. The typical result is an oops, UBSAN/KASAN report, or panic (denial of service); corruption of neighboring kernel objects is possible but not demonstrated in the wild. No privileges or user interaction are required once the attacker is adjacent. No named threat actors, ransomware campaigns, or public exploits are associated with this issue.

How to fix it

Install the Linux kernel update from your distribution or device vendor that includes the rtlwifi rtl8192du fix: validate the QoS TID before indexing sta_entry->tids[] and keep the default RTL_AGG_STOP state for out-of-range TIDs, matching rtl92cu_tx_fill_desc(). Custom kernels should merge the corresponding upstream rtl8192du change. No per-package fixed versions were published with this record, so follow distro/stable/LTS advisories for this CVE. Until patched, unload rtl8192du if the adapter is unused, use a different wireless NIC, or keep affected devices off untrusted wireless networks.

How to confirm the fix worked

Confirm the running kernel changelog or source for drivers/net/wireless/realtek/rtlwifi/rtl8192du (or the distro equivalent) contains a TID range check in rtl92du_tx_fill_desc before indexing tids[]. After upgrade, boot the new kernel, load rtl8192du, and verify dmesg/journal have no UBSAN array-index-out-of-bounds against type rtl_tid_data [9] and that normal QoS traffic (TID 0–7) still transmits. Inventory remaining exposure with module and hardware checks for rtl8192du/RTL8192DU on Linux endpoints and embedded images.

Typical attack path

1. Obtain adjacent Wi-Fi or RF proximity to a Linux host whose rtlwifi rtl8192du module is loaded
2. Cause the kernel TX path to process an 802.11 QoS frame with a TID above 8
3. Trigger rtl92du_tx_fill_desc() to index past sta_entry->tids[MAX_TID_COUNT]
4. Induce an out-of-bounds kernel access that oopses, panics, or corrupts nearby aggregation/station state

How to detect it

Successful abuse is most likely to leave a kernel oops, panic, or sanitizer report rather than a persistent implant. Search kernel logs (journalctl -k, dmesg, kern.log, kdump/vmcore) on systems with RTL8192DU hardware for out-of-bounds access in rtlwifi/rtl8192du, faults in rtl92du_tx_fill_desc, and references to rtl_tid_data [9]. Correlate unexpected reboots of those hosts with time on untrusted Wi-Fi. There are no known malware families, ransomware notes, or APT campaigns tied to this CVE; treat coincident wireless-path crashes as possible exploitation attempts. Production hunting does not require enabling UBSAN.

• array-index-out-of-bounds access with index 10 for type 'rtl_tid_data [9]'
• UBSAN: array-index-out-of-bounds
• rtl92du_tx_fill_desc
• Oops:.*rtl8192du
• Oops:.*rtlwifi
• rtl_tid_data
• KASAN: slab-out-of-bounds
• Call Trace:.*rtl92du

What your security team should do

• Patch Linux kernels that ship rtlwifi/rtl8192du as soon as distro or vendor updates are available
• Inventory hosts and images that load rtl8192du or use RTL8192DU adapters, especially on guest or untrusted Wi-Fi
• Until patched, unload unused rtl8192du modules and keep affected devices off untrusted adjacent wireless networks
• Watch kernel logs and crash dumps for rtl8192du/rtlwifi oops and UBSAN/KASAN tids-array reports
• Do not treat this as KEV/ransomware-urgent: EPSS is low and stable and exploit maturity is none, but still close it in the normal high-severity kernel cycle