Cloudanix VulnDB

CVE-2026-64440

High · 8.1

CVSS

8.1

EPSS

0.3%

Published

Jul 25, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A nearby malicious Wi-Fi hotspot could crash or interfere with some Linux devices that use a vulnerable Realtek wireless driver.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is an out-of-bounds write in the Linux kernel staging Realtek rtl8723bs wireless driver. When a client using this driver processes an 802.11 Association Response from an access point, the driver copies the HT Capabilities information element using the element length supplied over the air. The destination buffer is 26 bytes, but the attacker-controlled length can be up to 255 bytes, allowing writes beyond the end of the HT capability array into adjacent kernel driver state. A successful exploit can corrupt kernel memory, causing a crash or potentially altering kernel data structures, resulting in high integrity and availability impact. The attack is adjacent-network: the attacker must be within Wi-Fi radio range or able to impersonate an access point the device will join.

Why it matters to the business

Devices using the affected rtl8723bs Wi-Fi driver can be crashed or potentially manipulated by a malicious nearby Wi-Fi access point. This is most relevant to Linux-based laptops, tablets, embedded systems, kiosks, IoT devices, and appliances using Realtek RTL8723BS-class wireless hardware. Because exploitation requires Wi-Fi proximity, the internet-scale risk is lower than for remote network services, and current public exploit maturity and EPSS are low; however, the impact can still be operationally significant in locations where attackers can place rogue access points, such as offices, public venues, warehouses, campuses, and branch sites.

How an attack unfolds

An attacker sets up or controls a Wi-Fi access point within range of a vulnerable Linux device. The attacker may advertise a network name the device is configured to trust, use an evil-twin access point, or wait for a user or device to connect to the rogue network. During the 802.11 association process, the malicious access point sends an Association Response containing an HT Capabilities information element with an oversized length field. The vulnerable rtl8723bs driver trusts that length and copies more data than the fixed-size kernel buffer can hold. The excess bytes overwrite adjacent fields in kernel memory. Depending on memory layout and attacker control, this can lead to a kernel panic, wireless stack failure, denial of service, or potentially controlled corruption of kernel state.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the rtl8723bs HT_caps_handler() bounds-checking fix. If distribution-specific fixed package versions are not available, use the latest stable kernel or vendor security kernel for the affected platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the rtl8723bs driver, disabling Wi-Fi on affected systems, using wired networking, restricting automatic Wi-Fi association, and avoiding untrusted or public wireless networks. For embedded products and appliances, obtain updated firmware from the device vendor and verify that the kernel driver patch has been backported.

How to confirm the fix worked

Confirm whether systems use the affected driver by checking loaded modules and hardware inventory for rtl8723bs or Realtek RTL8723BS wireless devices. Validate remediation by confirming the running kernel package includes the upstream fix that limits HT_caps_handler() copying to the size of HT_caps.u.HT_cap. On Linux systems, review `uname -a`, distribution kernel package changelogs, `/proc/modules`, `lsmod`, `modinfo rtl8723bs`, and vendor advisories. In a test environment only, wireless protocol testing can confirm that oversized HT Capabilities elements no longer cause kernel warnings, crashes, or memory-safety reports. Production validation should focus on patch level and absence of the vulnerable driver rather than active exploit testing.

Typical attack path

  1. Identify or attract Linux devices using the Realtek rtl8723bs wireless driver within Wi-Fi range.
  2. Configure a rogue or evil-twin access point likely to be joined by the target device.
  3. Send an 802.11 Association Response with an oversized HT Capabilities information element.
  4. Trigger the vulnerable HT_caps_handler() path in the rtl8723bs driver during association.
  5. Overwrite memory adjacent to the fixed 26-byte HT capability buffer.
  6. Cause kernel instability, crash the device, disrupt wireless connectivity, or attempt further kernel memory corruption.

How to detect it

Look for signs of exploitation in kernel logs, crash dumps, wireless association telemetry, and wireless packet captures. Useful sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, persistent crash dumps, KASAN/KFENCE reports, wpa_supplicant logs, NetworkManager logs, and wireless IDS/WIPS captures. Suspicious host-side indicators include kernel oops or panic events involving rtl8723bs, HT_caps_handler(), association processing, or memory corruption shortly after joining a Wi-Fi network. Network-side detection requires 802.11 management-frame visibility: look for Association Response frames containing an HT Capabilities information element with a length greater than 26 bytes, particularly from unfamiliar, duplicate, or rapidly appearing SSIDs/BSSIDs. Because this issue is triggered before normal IP traffic is established, traditional firewall and network flow logs are unlikely to show the exploit. Absence of logs does not rule out exploitation if kernel logging or crash persistence was not enabled.

  • rtl8723bs
  • HT_caps_handler
  • BUG: KASAN: slab-out-of-bounds
  • BUG: KASAN: out-of-bounds
  • kernel BUG at
  • Oops:
  • Kernel panic - not syncing
  • /var/log/kern.log
  • /var/log/messages
  • journalctl -k
  • wpa_supplicant
  • Association Response
  • HT Capabilities
  • Tag: HT Capabilities
  • HT Capabilities IE length > 26
  • wlan0: associated
  • NetworkManager

What your security team should do

  • Prioritize inventory of Linux devices with Realtek RTL8723BS/rtl8723bs wireless hardware, especially embedded, kiosk, mobile, and branch-office devices.
  • Patch affected systems to a kernel or firmware build containing the rtl8723bs bounds-checking fix.
  • If patching is delayed, disable the rtl8723bs driver or Wi-Fi capability on exposed devices where operationally feasible.
  • Disable automatic connection to open, public, or weakly trusted Wi-Fi networks on systems that may carry the affected driver.
  • Monitor for rogue or evil-twin access points in sensitive facilities using wireless IDS/WIPS capabilities.
  • Review kernel logs and crash telemetry for rtl8723bs-related oops, panic, KASAN, or association-time failures.
  • Treat unexplained kernel crashes occurring immediately after Wi-Fi association as potentially suspicious until ruled out.
  • Track vendor advisories because fixed versions may be distributed through downstream kernel and firmware updates rather than a standalone driver package.

The record

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.

Affected packages

Ecosystem Package Introduced Fixed