CVE-2026-64536
High · 8.1CVSS
8.1
EPSS
0.2%
Published
Jul 27, 2026
CISA due date
—
Cloudanix analysis
A nearby attacker could use malicious Wi-Fi signals to crash or potentially extract sensitive data from some Linux devices using a specific Realtek wireless driver.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
This is an out-of-bounds read vulnerability in the Linux kernel staging Realtek rtl8723bs wireless driver. The vulnerable code parses Wi-Fi information elements without first confirming that the advertised element header and payload length are fully present in the received buffer. A malformed or truncated 802.11 information element can cause the kernel driver to read beyond the valid buffer while checking for TKIP-related information. Depending on kernel configuration and memory layout, this can lead to kernel memory disclosure or a kernel crash/panic, resulting in denial of service. Exploitation requires an attacker to be within wireless range or otherwise able to present crafted Wi-Fi management frames to a system using the affected driver.
Why it matters to the business
Affected systems with the vulnerable rtl8723bs driver enabled may be disrupted by a nearby attacker using malicious Wi-Fi frames, potentially causing device crashes, loss of network connectivity, or system instability. In higher-risk cases, the flaw may expose kernel memory contents, which could help an attacker bypass defenses or support follow-on exploitation. The issue is not listed in CISA KEV, has no known mature public exploit based on the provided data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, exposure is more relevant for laptops, embedded systems, IoT devices, kiosks, or operational devices using Realtek RTL8723BS Wi-Fi hardware in locations where untrusted wireless proximity is possible.
How an attack unfolds
An attacker positions themselves within radio range of a target system using the affected Realtek rtl8723bs Linux driver. They transmit crafted Wi-Fi management traffic, such as beacon or probe-response frames, containing malformed or truncated information elements. When the target wireless stack processes the advertised network information, the rtl8723bs driver enters the vulnerable parsing loop in is_ap_in_tkip(). Because the code does not sufficiently validate that the element header and payload are inside the received buffer, it may read past the end of the buffer while inspecting vendor-specific or RSN elements. The immediate result may be a kernel fault, driver instability, or system crash; in some circumstances, out-of-bounds memory reads may expose sensitive kernel memory contents or aid further attack development.
How to fix it
Upgrade to a Linux kernel version or vendor kernel package that includes the fix adding bounds checks in the rtl8723bs is_ap_in_tkip() information-element parsing loop. Because no exact fixed package versions were provided, use the latest security-supported kernel from the operating system or device vendor and confirm that it contains the upstream fix for the rtl8723bs out-of-bounds read in is_ap_in_tkip(). Where immediate patching is not possible, mitigate by disabling the rtl8723bs driver if the hardware is not required, disabling Wi-Fi on affected systems, using alternative supported wireless hardware/drivers, restricting use of affected devices in untrusted wireless environments, and monitoring for kernel crashes related to rtl8723bs. For embedded or appliance-like systems, obtain firmware or kernel updates from the device manufacturer.
How to confirm the fix worked
Confirm whether systems load the affected driver by checking for the rtl8723bs kernel module and Realtek RTL8723BS hardware. Validate remediation by verifying the running kernel package version against the operating-system or device-vendor advisory and, where source-level validation is possible, confirming that the rtl8723bs is_ap_in_tkip() parser includes explicit remaining-length checks for information-element headers and minimum payload lengths before accessing vendor-specific and RSN fields. After patching, reboot into the fixed kernel and confirm the vulnerable module is no longer present or is the fixed version. Also review recent kernel logs for rtl8723bs-related oops, panic, KASAN, UBSAN, or out-of-bounds-read reports to determine whether malformed wireless frames may have triggered the bug before remediation.
Typical attack path
- Identify systems likely to use the Linux rtl8723bs wireless driver or Realtek RTL8723BS Wi-Fi hardware.
- Move within wireless range of the target device or operate a rogue access point in the same physical area.
- Broadcast or respond with crafted 802.11 management frames containing malformed, truncated, or length-inconsistent information elements.
- Trigger the target system to scan, discover, or evaluate the malicious wireless network advertisement.
- Cause the vulnerable driver parser to read beyond the valid information-element buffer.
- Observe resulting effects such as wireless driver failure, kernel oops, system crash, or potential memory disclosure behavior.
How to detect it
Look for evidence of exploitation or attempted triggering in kernel and system logs rather than conventional network perimeter logs, because exploitation occurs over local 802.11 wireless management frames. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops records, kernel oops reports, KASAN/UBSAN reports, and endpoint telemetry showing module load state. Search for rtl8723bs-related crashes, stack traces referencing is_ap_in_tkip(), out-of-bounds read reports, wireless-driver resets, or kernel panics occurring while the system was scanning or associating with nearby Wi-Fi networks. If wireless monitoring is available, review captures for malformed beacon or probe-response frames with truncated information elements, inconsistent information-element lengths, abnormal vendor-specific elements, or malformed RSN elements. Absence of logs does not prove absence of exploitation, because a kernel crash may prevent complete logging and memory disclosure attempts may not create durable artifacts.
- rtl8723bs
- is_ap_in_tkip
- BUG: KASAN: slab-out-of-bounds
- BUG: KASAN: global-out-of-bounds
- BUG: KASAN: out-of-bounds
- kernel BUG at
- Oops:
- Kernel panic - not syncing
- rtl8723bs:
- r8723bs
- WLAN_EID_VENDOR_SPECIFIC
- WLAN_EID_RSN
- /var/log/kern.log
- /var/log/messages
- /sys/module/rtl8723bs
- /sys/module/r8723bs
- /sys/fs/pstore/
- /proc/modules
What your security team should do
- Inventory Linux laptops, embedded devices, IoT systems, kiosks, and appliances for Realtek RTL8723BS Wi-Fi hardware or the loaded rtl8723bs kernel module.
- Prioritize patching systems that use Wi-Fi in public, shared, or physically accessible areas where an attacker could be within radio range.
- Update affected systems to the latest vendor-supported kernel or firmware containing the rtl8723bs bounds-checking fix.
- Disable the rtl8723bs driver or Wi-Fi functionality on systems where wireless connectivity is not required.
- Collect and review kernel logs for rtl8723bs crashes, KASAN out-of-bounds reports, unexplained kernel oops events, or repeated wireless-driver resets.
- For managed fleets, add detection logic for loaded rtl8723bs modules and kernel versions below the vendor-fixed release.
- Treat unexplained crashes on affected wireless devices as potentially security-relevant until logs and physical wireless exposure are reviewed.
The record
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|