CVE-2026-46305

What it actually does

This is a Linux kernel NULL pointer dereference in the staging Realtek RTL8723BS wireless driver. The driver allocates a flexible structure with kzalloc_flex() in rtw_cbuf_alloc() but previously dereferenced the returned pointer without first confirming allocation success. If memory allocation fails, the kernel can dereference NULL, causing a kernel oops and potentially a system crash or reboot depending on kernel configuration such as panic_on_oops. The practical impact is denial of service on systems using the affected rtl8723bs driver.

Why it matters to the business

Affected systems can become unstable or unavailable if the vulnerable wireless driver is loaded and the allocation failure path is triggered. This is most relevant to Linux-based laptops, embedded devices, IoT systems, kiosks, or appliances using Realtek RTL8723BS Wi-Fi hardware. The current exploitation signal is low: EPSS is 0.001, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity is reported. However, kernel crashes on edge or embedded devices can still cause operational disruption, service interruption, and support costs.

How an attack unfolds

An attacker would first need a system where the rtl8723bs staging driver is present and loaded. Exploitation depends on causing or waiting for memory pressure so that kzalloc_flex() fails during rtw_cbuf_alloc(). The attacker then triggers driver activity that reaches the vulnerable allocation path. Because the old code used the allocation result without checking for NULL, the kernel dereferences a NULL pointer. The result is a kernel oops, and on systems configured to panic on oops, this can become a full denial-of-service crash or reboot. There is no indication from the provided intelligence that this enables privilege escalation, code execution, data theft, or ransomware activity.

How to fix it

Apply a Linux kernel update that includes the fix for the rtl8723bs rtw_cbuf_alloc() NULL pointer dereference. If vendor-fixed versions are not yet mapped, use the latest kernel packages from the operating system or device vendor that include the upstream fix. For embedded or appliance builds, backport the patch that checks the kzalloc_flex() return value before dereferencing it. If immediate patching is not possible, mitigate by disabling or unloading the rtl8723bs driver where the hardware is not required, blacklisting the module, reducing untrusted local access, and monitoring for memory pressure or repeated kernel oops events. Systems that do not include or load the rtl8723bs driver are unlikely to be exposed to this specific flaw.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vulnerable rtl8723bs driver and whether the module is loaded. Validate remediation by verifying the installed kernel package or source tree contains the NULL-check fix in rtw_cbuf_alloc(), then reboot into the patched kernel. On running systems, check module status with tools such as lsmod and modinfo for rtl8723bs, verify the active kernel version with uname -a, and confirm the vendor advisory or changelog includes the fix. Also review dmesg or journal logs after driver activity to ensure there are no recurring NULL pointer dereferences or kernel oops messages involving rtw_cbuf_alloc or rtl8723bs.

Typical attack path

1. Identify a Linux system using the Realtek RTL8723BS wireless driver or a kernel build that includes the staging rtl8723bs module.
2. Confirm the driver is loaded or can be exercised through wireless interface activity.
3. Create or wait for memory pressure that increases the likelihood of kzalloc_flex() returning NULL.
4. Trigger driver code paths that call rtw_cbuf_alloc().
5. Cause the driver to dereference a NULL pointer after allocation failure.
6. Induce a kernel oops, system instability, or a crash/reboot if panic-on-oops behavior is enabled.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, crash dumps, and reboot records for NULL pointer dereferences involving the rtl8723bs driver or rtw_cbuf_alloc(). Useful sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald, kdump/vmcore artifacts, pstore/ramoops logs on embedded systems, watchdog reboot logs, and endpoint telemetry that records kernel panics or unexpected reboots. Look for crashes preceded by memory allocation failures, out-of-memory pressure, rtl8723bs wireless activity, or repeated driver initialization/reset events. Because this vulnerability is a denial-of-service condition and not known to provide code execution, detection should focus on crash artifacts and availability events rather than persistence or lateral movement indicators.

• rtl8723bs
• rtw_cbuf_alloc
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• kzalloc_flex
• kernel panic
• Kernel panic - not syncing
• Oops:
• panic_on_oops
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /var/crash
• vmcore
• ramoops

What your security team should do

• Prioritize patching Linux systems that use Realtek RTL8723BS wireless hardware, especially embedded, kiosk, IoT, or edge devices where crashes create operational impact.
• Inventory systems with the rtl8723bs module present or loaded using endpoint telemetry, package inventory, or kernel module scans.
• Update affected systems to a vendor kernel containing the fix, or backport the upstream NULL-check patch for custom kernels.
• Where the driver is unnecessary, blacklist or remove the rtl8723bs module to eliminate exposure.
• Monitor kernel logs for oops, panic, NULL pointer dereference, and rtl8723bs-related crash messages.
• Treat this as lower internet-scale urgency because EPSS is low, it is not in KEV, and no public exploit maturity is reported, but still remediate in normal kernel maintenance cycles due to availability risk.