CVE-2026-46092

What it actually does

This is a local denial-of-service flaw in the Linux kernel Realtek rtw88 Wi-Fi PCI driver. When a Realtek RTL8821CE/8821CE Wi-Fi device is attached in a PCI topology where the device is on a root bus and has no upstream PCI bridge, the driver probe path can dereference a NULL return value from pci_upstream_bridge(). The result is a kernel crash during device initialization or driver probing. The impact is availability only; the described issue does not provide confidentiality or integrity impact and does not indicate privilege escalation or remote code execution.

Why it matters to the business

Affected Linux systems with the vulnerable kernel and the relevant Realtek rtw88 PCI Wi-Fi hardware/topology can crash when the device is initialized, causing workstation or appliance downtime, failed boots, interrupted wireless connectivity, and potential operational disruption. The risk is most relevant for physical or locally managed systems where users or administrators can add, enable, or trigger probing of the affected PCI Wi-Fi device. Public exploitation likelihood appears low based on the low EPSS score, no known exploited status, no ransomware association, and no public exploit maturity reported, but kernel crashes can still materially affect availability for exposed device fleets.

How an attack unfolds

An attacker needs local capability to influence hardware presence, driver loading, or device probing. The vulnerable path is reached when the Linux kernel rtw88 PCI driver probes an affected Realtek 8821CE-class Wi-Fi device installed in a PCI configuration that lacks an upstream bridge. The driver assumes pci_upstream_bridge() returns a valid bridge pointer, but on a root bus it can return NULL. If the driver continues into the workaround logic without checking that pointer, the kernel dereferences NULL and crashes. In practical terms, exploitation is most plausible through local physical access, malicious or accidental hardware configuration, or a local user with sufficient permissions to bind/unbind or reload the affected driver/module and trigger probing of the device.

How to fix it

Update affected Linux kernels to a vendor release that includes the rtw88 fix adding a NULL check before applying the PCI upstream-bridge-specific workaround. Because no exact fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or kernel vendor security advisory. Where immediate patching is not possible, mitigate by avoiding affected Realtek RTL8821CE/8821CE Wi-Fi hardware on vulnerable systems, disabling the affected rtw88/rtw88_8821ce PCI driver, blacklisting the module if wireless functionality is not required, or preventing untrusted users from loading/unloading kernel modules or changing PCI driver bindings. These mitigations may disable Wi-Fi capability and should be tested before broad deployment.

How to confirm the fix worked

Confirm that systems run a kernel build containing the upstream/vendor rtw88 PCI bridge-existence check. Validate package versions against the Linux distribution’s advisory or changelog for this issue. On representative hardware, verify that booting, loading the rtw88 driver, rescanning PCI, and binding the Realtek 8821CE device no longer cause a kernel oops or panic. Check whether the affected modules are present and loaded using tools such as lsmod and modinfo, and identify relevant hardware with lspci. For mitigations, confirm that the affected module is blocked or absent, that the device is not bound to the vulnerable driver, and that wireless functionality changes are documented and expected.

Typical attack path

1. Obtain local access or administrative capability to influence PCI device initialization, driver binding, or module loading.
2. Ensure an affected Realtek RTL8821CE/8821CE Wi-Fi PCI device is present in a PCI topology where the device is on a root bus without an upstream bridge.
3. Trigger the vulnerable rtw88 PCI probe path, such as by booting the system, loading the affected module, rescanning PCI, or binding the driver to the device.
4. The driver calls pci_upstream_bridge(), receives NULL, and follows code that incorrectly assumes a bridge exists.
5. The kernel dereferences the NULL pointer and crashes, causing a local denial of service.

How to detect it

Look for evidence of prior kernel oops, panic, or crash events occurring during Realtek rtw88/RTL8821CE Wi-Fi driver initialization. Useful sources include journald, syslog, kern.log, dmesg output, persistent pstore records, kdump/vmcore artifacts, crash dump directories, and endpoint telemetry that records kernel panics or reboots. Search for NULL pointer dereference messages near rtw88, rtw88_8821ce, rtw88_pci, RTL8821CE, or PCI probe/bind activity. Correlate crash timestamps with module load/unload events, PCI rescans, system boots, udev hardware events, and local administrative commands. Because this issue is a local availability bug and no public exploitation or known exploited status is reported, absence of a network IOC is expected; detection should focus on host crash artifacts and kernel log context.

• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: 0000
• rtw88_8821ce
• rtw88_pci
• rtw88_core
• RTL8821CE
• 8821CE
• pci_upstream_bridge
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /sys/fs/pstore
• /var/crash
• /var/lib/systemd/coredump
• module rtw88_8821ce
• modprobe rtw88_8821ce

What your security team should do

• Prioritize patching Linux endpoints or appliances that use Realtek RTL8821CE/8821CE Wi-Fi hardware with the rtw88 PCI driver, especially systems where local users can reload modules or where uptime is critical.
• Inventory systems for Realtek 8821CE-class PCI Wi-Fi devices and loaded rtw88-related modules to scope exposure.
• Apply the vendor-provided kernel update containing the rtw88 NULL-check fix; if unavailable, track the distribution kernel advisory until a fixed package is released.
• Use temporary mitigations, such as blacklisting rtw88_8821ce or disabling the affected wireless device, on high-availability systems where the hardware is not required.
• Restrict local administrative actions that can trigger driver probing, including kernel module loading/unloading, PCI rescans, and manual driver binding.
• Monitor kernel logs for NULL pointer dereference, oops, or panic events associated with rtw88/rtw88_8821ce probing.
• Treat repeated kernel crashes during Wi-Fi initialization as a potential exploitation or reliability signal and preserve logs, crash dumps, and hardware inventory data for analysis.