CVE-2026-64442

What it actually does

This flaw is an out-of-bounds read in the Linux kernel staging rtl8723bs wireless driver. The driver parses 802.11 information elements from access point beacon and probe-response frames without first confirming that enough bytes remain for the element header and declared element length. A malformed frame that ends with a truncated information element can cause the driver to read past the end of the received buffer while handling association request generation or station join processing. Depending on kernel build, memory layout, and hardening features, impact can include kernel memory disclosure, kernel warning/Oops, driver instability, or system crash. The attack is adjacent-network: the attacker must be within Wi-Fi radio range or otherwise able to present malicious beacon/probe-response frames to a vulnerable device using the rtl8723bs driver.

Why it matters to the business

Affected Linux devices with the Realtek RTL8723BS staging wireless driver enabled may be disrupted by a nearby rogue or compromised Wi-Fi access point. Practical consequences include device crashes, loss of wireless connectivity, service interruption for kiosks/embedded systems/IoT endpoints, and potential exposure of kernel memory. The issue has a high CVSS score because it requires no authentication or user interaction beyond normal Wi-Fi scanning/join behavior, but current exploitation signals are low: EPSS is low, no public exploit maturity is indicated, and it is not listed in CISA KEV or known ransomware use. Organizations with fleets of Linux-based embedded or mobile devices using this chipset should still prioritize patching because exploitation only requires physical/radio proximity.

How an attack unfolds

An attacker positions a malicious access point within Wi-Fi range of a vulnerable Linux system using the rtl8723bs driver. The attacker broadcasts beacon frames or responds to probe requests with crafted 802.11 information element data where the final element is truncated: it contains an element ID byte but not the full length byte, or declares a length that extends beyond the received buffer. When the vulnerable device scans, evaluates, or attempts to join the network, the driver copies or stores the AP information and later walks the information element buffer in issue_assocreq() or join_cmd_hdl(). Because the loop dereferences the element length before validating that the complete header remains, the kernel reads one byte or more past the buffer boundary. This can trigger kernel memory exposure paths, a KASAN/slab out-of-bounds report on instrumented kernels, driver failure, or a kernel Oops/panic that disrupts the device. Exploitation does not require credentials on the target and can be launched using Wi-Fi proximity, but it is constrained to systems with the affected driver and radio conditions that cause the target to process the malicious AP frames.

How to fix it

Update to a Linux kernel or vendor kernel package that includes the rtl8723bs bounds-check fix for information element parsing in issue_assocreq() and join_cmd_hdl(). If exact fixed package versions are not available from the advisory data, use the latest stable kernel provided by the operating system, device, or appliance vendor and confirm that the patch adds both guard checks: stop parsing when fewer than a complete IE header remains, and stop parsing when the declared IE length extends past the buffer end. Where immediate patching is not possible, reduce exposure by disabling Wi-Fi on affected systems, blacklisting/unloading the rtl8723bs module if not required, using wired networking, restricting devices from joining untrusted Wi-Fi, and limiting operation in hostile radio environments. Embedded-device maintainers should rebuild images with a fixed kernel and redistribute firmware updates to downstream devices.

How to confirm the fix worked

Confirm whether systems are exposed by checking for the rtl8723bs driver/module and compatible Realtek RTL8723BS hardware. On Linux, review loaded modules with commands such as lsmod, modinfo rtl8723bs, and dmesg output referencing rtl8723bs or r8723bs. Confirm remediation by verifying the running kernel package/version is at or newer than the vendor-fixed build and, where source validation is possible, confirm the IE parsing loops in issue_assocreq() and join_cmd_hdl() check that at least sizeof(*pIE) bytes remain before reading pIE->length and verify that pIE->length does not extend beyond the buffer end. After patching, retest wireless scanning and association behavior and ensure no KASAN, Oops, or rtl8723bs parsing errors occur when exposed to malformed beacon/probe-response frames in a controlled lab.

Typical attack path

1. Identify or wait for Linux devices using the Realtek RTL8723BS wireless chipset/rtl8723bs driver within Wi-Fi range.
2. Set up a rogue access point or frame-injection device broadcasting beacon frames or responding to probe requests.
3. Craft beacon or probe-response information elements so the final IE is truncated or declares data beyond the available buffer.
4. Cause the vulnerable device to scan for networks or attempt to join the malicious network.
5. Trigger parsing in the rtl8723bs issue_assocreq() or join_cmd_hdl() code path.
6. Observe impact such as wireless driver instability, kernel warning/Oops, system crash, or possible kernel memory disclosure depending on platform and hardening.

How to detect it

Detecting prior exploitation is difficult because the trigger is a malformed Wi-Fi management frame and may leave only kernel crash or driver instability artifacts. Review kernel logs, system journals, crash dumps, and endpoint telemetry for rtl8723bs activity around the time of Wi-Fi scans, roaming, or association attempts. Look for KASAN, slab-out-of-bounds, out-of-bounds read, kernel Oops, panic, or general protection fault messages referencing issue_assocreq(), join_cmd_hdl(), rtl8723bs, r8723bs, or 802.11 information element parsing. Correlate these events with wireless logs showing association attempts to unfamiliar SSIDs/BSSIDs, sudden AP changes, duplicate SSIDs, deauthentication/roaming bursts, or operation in locations where rogue APs are plausible. If wireless IDS/packet captures are available, examine beacon and probe-response frames near the incident time for truncated final information elements or element lengths that exceed the remaining frame body. Forensic triage should include determining whether the rtl8723bs module was loaded, whether the device crashed or rebooted unexpectedly, and whether crash dumps contain stack traces through the affected functions.

• rtl8723bs
• r8723bs
• issue_assocreq
• join_cmd_hdl
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• slab-out-of-bounds in issue_assocreq
• slab-out-of-bounds in join_cmd_hdl
• out-of-bounds read in issue_assocreq
• out-of-bounds read in join_cmd_hdl
• kernel BUG at drivers/staging/rtl8723bs
• Oops:
• Kernel panic
• general protection fault
• /sys/module/rtl8723bs
• /lib/modules/*/kernel/drivers/staging/rtl8723bs
• 802.11 IE length exceeds remaining buffer
• truncated information element

What your security team should do

• Inventory Linux endpoints, embedded devices, kiosks, tablets, and appliances for Realtek RTL8723BS hardware or the rtl8723bs kernel module.
• Prioritize updates for devices that use Wi-Fi in public, shared, industrial, retail, healthcare, transportation, or other environments where rogue access points could be nearby.
• Apply the latest vendor kernel or firmware update containing the rtl8723bs information-element bounds-check fix.
• If patching is delayed, disable or blacklist the rtl8723bs driver on systems that do not require that wireless adapter.
• For critical devices, prefer wired networking or managed/trusted Wi-Fi environments until patched.
• Monitor kernel logs and crash telemetry for rtl8723bs, issue_assocreq(), join_cmd_hdl(), KASAN out-of-bounds, Oops, or panic events correlated with Wi-Fi scanning/association.
• Review wireless infrastructure monitoring for rogue APs, unexpected SSIDs, duplicate SSIDs, and suspicious beacon/probe-response activity near sensitive facilities.
• Because this is not currently in KEV, has low EPSS, and has no known mature exploit, schedule remediation based on device criticality and physical exposure rather than treating it as an internet-scale emergency.