CVE-2026-43386

What it actually does

This flaw is an out-of-bounds read in the Linux kernel staging rtl8723bs wireless driver function that restructures WMM information elements. The driver can access in_ie[i + 5] before verifying that the buffer is long enough. A local, low-privileged attacker who can cause the vulnerable driver path to process crafted wireless management information may be able to make the kernel read memory past the end of the supplied buffer. The most likely impacts are kernel memory disclosure or a kernel fault/panic, resulting in loss of confidentiality and availability. There is no direct indication from the published description that the bug enables arbitrary code execution or data modification.

Why it matters to the business

Systems using the affected Linux kernel with the rtl8723bs wireless driver exposed may be at risk of local denial of service through kernel crashes and potential leakage of sensitive kernel memory. The risk is most relevant to laptops, embedded devices, IoT systems, and appliances using Realtek RTL8723BS-class wireless hardware or distributions that ship the staging driver. Although EPSS is currently very low and there is no known CISA KEV listing or public exploit maturity, kernel flaws can have outsized operational impact because a successful attack can crash the whole device rather than only one application.

How an attack unfolds

An attacker first needs local access or another realistic way to influence data processed by the rtl8723bs wireless driver. The attacker targets a system running an affected Linux kernel where the rtl8723bs staging driver is loaded and the relevant wireless functionality is active. They then cause the vulnerable WMM information element parsing path to receive a malformed or short input buffer. Because the vulnerable code reads an offset before confirming the buffer length, the kernel may read beyond the valid bounds of the input. Depending on memory layout and kernel behavior, this may expose adjacent kernel memory to the attacker or trigger a kernel oops/panic, causing device disruption. Practical exploitation is likely hardware- and configuration-dependent and is currently not known to be broadly weaponized.

How to fix it

Apply the Linux kernel update from the operating system or device vendor that includes the fix for the rtl8723bs rtw_restruct_wmm_ie bounds check issue. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories and distribution-specific kernel package releases. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the rtl8723bs driver if the hardware is not required, removing unused wireless functionality on embedded devices, restricting local shell access, and limiting untrusted code execution. For systems that require the affected hardware, prioritize vendor-supported kernel updates over ad hoc source changes.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the rtl8723bs bounds-check fix. Validate package state using the relevant distribution tools, such as checking the installed kernel version and vendor changelog for the rtl8723bs or rtw_restruct_wmm_ie fix. Confirm whether the module is present or loaded using commands such as lsmod, modinfo rtl8723bs, and checking /sys/module/rtl8723bs. If mitigation is used instead of patching, verify the driver cannot load through module blacklist configuration and after reboot confirm it is absent from lsmod. Review kernel logs after validation testing to ensure there are no rtl8723bs-related oops, panic, or slab/KASAN out-of-bounds reports.

Typical attack path

1. Identify a Linux system running an affected kernel with the rtl8723bs wireless driver present or loaded.
2. Obtain local code execution or another means to influence wireless driver input handled by the affected parsing routine.
3. Craft malformed wireless/WMM information element data that is shorter than the code expects.
4. Trigger the rtw_restruct_wmm_ie parsing path in the rtl8723bs driver.
5. Cause an out-of-bounds kernel memory read, potentially resulting in kernel memory disclosure or a kernel crash.
6. If the system crashes, use the denial of service impact to disrupt device availability; if memory is exposed, attempt to use leaked information to support further exploitation.

How to detect it

Look for evidence of attempted triggering in kernel and system logs rather than relying on network indicators, because this issue is a kernel driver memory-safety flaw and no public exploit-specific IOC is available. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump repositories, pstore/ramoops, kernel oops reports, EDR kernel panic telemetry, and KASAN/KMSAN reports on debug kernels. Search for rtl8723bs driver activity followed by kernel oops, BUG, panic, general protection fault, page fault, slab out-of-bounds, or KASAN out-of-bounds read messages, especially involving rtw_restruct_wmm_ie. Also investigate unexpected reboots or Wi-Fi driver resets on systems with Realtek RTL8723BS-class hardware. Because exploitation may only produce a crash and not a persistent artifact, absence of logs does not prove absence of attempted exploitation, particularly if kernel logs are not retained across reboot.

• rtl8723bs
• rtw_restruct_wmm_ie
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: KASAN: out-of-bounds
• out-of-bounds read
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• BUG: unable to handle page fault
• /sys/module/rtl8723bs
• /lib/modules/*/kernel/drivers/staging/rtl8723bs
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore

What your security team should do

• Inventory Linux endpoints, embedded devices, and appliances for affected kernels and loaded rtl8723bs wireless driver usage.
• Prioritize patching systems where rtl8723bs hardware is present, wireless is enabled, or untrusted users can execute local code.
• If the driver is not operationally required, blacklist or disable rtl8723bs as a near-term mitigation.
• Monitor vendor kernel advisories and distribution changelogs for fixed kernel builds because exact fixed versions were not provided.
• Review kernel logs and crash telemetry for rtl8723bs, rtw_restruct_wmm_ie, out-of-bounds read, KASAN, oops, or panic events that may indicate attempted triggering.
• Maintain normal hardening controls that reduce local exploitation risk, including least privilege, endpoint controls, restricted shell access, and preventing untrusted workloads from running on user or embedded devices.