CVE-2026-43225

What it actually does

This is a local denial-of-service flaw in the Linux kernel staging rtl8723bs wireless driver. When the driver processes a BSS frame and cfg80211_inform_bss_frame() fails, an allocated buffer is not freed on the failure path. Repeatedly triggering this path can leak kernel memory and eventually cause memory pressure, degraded system responsiveness, out-of-memory conditions, service disruption, or a kernel crash. The flaw does not provide confidentiality or integrity impact and is not known to enable privilege escalation or remote code execution.

Why it matters to the business

Systems using affected Linux kernels with the rtl8723bs wireless driver may become unstable or unavailable if a local user or process can repeatedly trigger the vulnerable Wi-Fi scanning/error path. The practical risk is service interruption on endpoints, embedded devices, kiosks, appliances, or IoT-style systems that use Realtek RTL8723BS Wi-Fi hardware. Public exploitation is not currently known, it is not listed in CISA KEV, and EPSS is very low and flat, so remediation should be handled through normal kernel maintenance unless the affected driver is present on high-availability or difficult-to-recover devices.

How an attack unfolds

An attacker first needs local access with sufficient ability to initiate or influence wireless scanning behavior on a system using an affected kernel and the rtl8723bs driver. The attacker repeatedly causes the driver to enter the code path where a BSS frame is processed and cfg80211_inform_bss_frame() returns failure. Because the allocated buffer is not released on that failure path, each failed iteration consumes additional kernel memory. Over time, accumulated leaks can exhaust available memory or create severe memory pressure, resulting in degraded performance, failed services, out-of-memory killer activity, or a system crash/reboot. No public exploit maturity is reported, and exploitation requires the vulnerable driver/hardware path to be active.

How to fix it

Apply a Linux kernel update from the operating system or device vendor that includes the rtl8723bs fix ensuring the allocated buffer is freed on both success and failure paths. No exact fixed package versions were provided, so track the vendor advisory or kernel changelog for the fix described as "staging: rtl8723bs: fix memory leak on failure path." Where immediate patching is not possible, reduce exposure by disabling or blacklisting the rtl8723bs driver if the hardware is not required, disabling Wi-Fi on affected systems where operationally acceptable, restricting local shell access, limiting untrusted users' ability to initiate wireless scans, and monitoring for memory pressure. Because this is a kernel-space issue, restart or reboot after applying the fixed kernel so the patched kernel and modules are loaded.

How to confirm the fix worked

Confirm whether exposure exists by checking the running kernel version against the distribution or vendor advisory and verifying whether the rtl8723bs module is present or loaded. On Linux systems, review outputs such as `lsmod | grep rtl8723bs`, `modinfo rtl8723bs`, package manager kernel version information, and `/sys/module/rtl8723bs` presence. After remediation, verify the system is booted into the updated kernel, the vulnerable module is no longer present or has been rebuilt from the fixed source, and no older vulnerable kernel remains the default boot option. Functional validation should include confirming Wi-Fi behavior still works where required and monitoring that repeated scan activity no longer causes increasing unreclaimed kernel memory or OOM events.

Typical attack path

1. Identify a Linux system using the Realtek RTL8723BS wireless driver or with the rtl8723bs module loaded.
2. Obtain local user-level access capable of triggering wireless scan behavior or interacting with the network stack through permitted interfaces.
3. Repeatedly initiate conditions that cause BSS frame processing and failure in cfg80211_inform_bss_frame().
4. Accumulate unreleased kernel memory allocations through repeated failure-path execution.
5. Cause memory pressure, out-of-memory events, degraded system availability, or a kernel crash.

How to detect it

To assess prior exploitation, focus on host telemetry rather than network indicators. Review kernel logs, system logs, journal entries, and endpoint telemetry for unexplained memory exhaustion, OOM killer activity, kernel warnings, unexpected reboots, or service failures on systems where rtl8723bs is loaded. Correlate memory-pressure events with repeated wireless scanning, NetworkManager or wpa_supplicant activity, local user sessions, scripts, or processes invoking Wi-Fi scan commands. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd process execution logs, EDR process telemetry, NetworkManager logs, wpa_supplicant logs, and crash dump/kdump artifacts. There are no known public attacker-specific indicators, threat actors, payloads, file drops, or network signatures for this issue, so detection should be behavior-based: repeated local scan activity followed by increasing kernel memory use, OOM kills, or kernel crashes on systems using rtl8723bs.

• rtl8723bs
• cfg80211_inform_bss_frame
• /sys/module/rtl8723bs
• Out of memory: Kill process
• oom-killer
• invoked oom-killer
• Memory cgroup out of memory
• NetworkManager
• wpa_supplicant
• iw dev
• iwlist scan
• kernel: Out of memory
• kernel: oom-killer

What your security team should do

• Inventory Linux systems and embedded devices that use Realtek RTL8723BS Wi-Fi hardware or load the rtl8723bs kernel module.
• Prioritize patching for systems where local users are untrusted, devices are physically accessible, or availability is operationally important.
• Apply vendor kernel updates containing the rtl8723bs memory-leak fix and reboot into the patched kernel.
• If the driver is unnecessary, blacklist or disable rtl8723bs to remove the vulnerable code path.
• Monitor affected systems for kernel memory pressure, OOM killer events, unexpected reboots, and repeated wireless scan activity until patched.
• Treat this as normal-priority maintenance for most environments because exploitation is local, EPSS is very low, there is no KEV listing, and no public exploit maturity is reported.