CVE-2026-53112

What it actually does

This is a Linux kernel use-after-free in the rtlwifi PCI driver. The driver initializes irq_prepare_bcn_tasklet during device setup and schedules it when a Realtek Wi-Fi beacon interrupt is raised, but teardown did not reliably cancel the pending tasklet before freeing the associated ieee80211_hw structure. If device initialization fails or the Wi-Fi device is detached while the tasklet is still queued or running, the tasklet can later dereference freed kernel memory in _rtl_pci_prepare_bcn_tasklet(). The most likely technical outcomes are kernel crash, denial of service, memory corruption, or potentially privilege-impacting behavior if an attacker can reliably control the race and freed-memory contents. Exploit maturity is currently reported as none and EPSS is very low, suggesting no broad exploitation signal at this time.

Why it matters to the business

Systems using affected Realtek rtlwifi PCI wireless hardware may be vulnerable to kernel instability during Wi-Fi device initialization, removal, suspend/resume, driver unload, or error handling. In business terms, this could cause endpoint crashes, service disruption, or degraded availability on laptops, workstations, kiosks, embedded Linux devices, or appliances that rely on the affected driver. Because this is kernel-level memory corruption, organizations should still treat it as a security-relevant stability issue even though it is not currently in CISA KEV, is not associated with ransomware use, and has a low EPSS score.

How an attack unfolds

An attacker would need to influence timing around a Realtek rtlwifi PCI device interrupt and driver teardown path. A plausible exploitation scenario starts with the affected system using a vulnerable kernel and rtlwifi PCI hardware. The attacker then causes or waits for a condition where the device is being detached, the driver is unloading, probe fails, or the interface is otherwise being torn down while a beacon interrupt-related tasklet remains pending. Because the tasklet was not killed during rtl_pci_deinit(), it may execute after the ieee80211_hw object has already been freed. When _rtl_pci_prepare_bcn_tasklet() accesses that freed object, the kernel may crash or corrupt memory. Reliable exploitation beyond denial of service would likely require strong control over race timing and kernel memory reuse, making exploitation non-trivial based on currently available information.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the rtlwifi PCI fix adding tasklet_kill() for irq_prepare_bcn_tasklet during rtl_pci_deinit(). If exact fixed package versions are not available from the advisory feed, use vendor kernel advisories for the deployed distribution and confirm the patch is included. Prioritize systems with Realtek rtlwifi PCI wireless adapters, especially portable endpoints and embedded devices where Wi-Fi is enabled. If immediate patching is not possible, reduce exposure by disabling the affected rtlwifi driver or affected wireless hardware where operationally feasible, preventing untrusted users from unloading/reloading kernel modules, restricting physical access to systems with affected adapters, and avoiding unnecessary suspend/resume or hotplug workflows until patched.

How to confirm the fix worked

Confirm exposure by checking whether the system has Realtek rtlwifi PCI hardware and loads rtlwifi-related kernel modules such as rtl_pci, rtlwifi, or chipset-specific modules. Confirm remediation by verifying the running kernel package version is at or above the vendor-fixed release and, where source validation is possible, that rtl_pci_deinit() kills irq_prepare_bcn_tasklet before ieee80211_hw is freed. After patching, reboot into the fixed kernel and verify the old vulnerable kernel is not still running. Functional validation can include loading and unloading the affected driver, restarting wireless networking, and exercising suspend/resume while monitoring dmesg or journal logs for kernel oops, KASAN use-after-free reports, tasklet warnings, or rtlwifi crashes.

Typical attack path

1. Identify a Linux system using vulnerable kernel code with Realtek rtlwifi PCI wireless hardware enabled.
2. Trigger or wait for rtlwifi device activity that schedules irq_prepare_bcn_tasklet, such as beacon interrupt handling.
3. Create or induce a teardown condition, such as driver unload, device detach, failed probe, reset, suspend/resume instability, or hardware error handling.
4. Win the race so the ieee80211_hw object is freed while irq_prepare_bcn_tasklet is still pending or running.
5. Cause the pending tasklet to execute and access freed kernel memory in _rtl_pci_prepare_bcn_tasklet().
6. Observe kernel crash, denial of service, or potentially memory-corruption side effects depending on exploit reliability and kernel hardening.

How to detect it

Look for evidence of kernel instability involving the rtlwifi PCI driver, especially around Wi-Fi device removal, driver unload, failed probe, suspend/resume, or interface reset. Relevant log sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, crash dump repositories, kdump/vmcore analysis, EDR kernel telemetry, and system availability monitoring. Search for kernel oops, panic, BUG, KASAN, KFENCE, slab corruption, or general protection fault messages that include rtlwifi, rtl_pci, irq_prepare_bcn_tasklet, _rtl_pci_prepare_bcn_tasklet, rtl_pci_deinit, or ieee80211_hw. Because no public exploitation artifacts or malware indicators are known, detection should focus on crash forensics and anomalous local administrative actions such as repeated modprobe/rmmod cycles for rtlwifi modules, unexpected PCI device unbind operations, or repeated Wi-Fi reset/suspend/resume events preceding a kernel crash.

• _rtl_pci_prepare_bcn_tasklet
• irq_prepare_bcn_tasklet
• rtl_pci_deinit
• rtl_pci_init
• RTL_IMR_BCNINT
• ieee80211_hw
• rtlwifi
• rtl_pci
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• KFENCE: use-after-free
• general protection fault
• kernel BUG
• Unable to handle kernel NULL pointer dereference
• Oops:
• modprobe rtlwifi
• modprobe rtl_pci
• rmmod rtlwifi
• rmmod rtl_pci
• /sys/bus/pci/drivers/rtl_pci/unbind
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems with Realtek rtlwifi PCI wireless adapters and affected rtlwifi kernel modules loaded.
• Patch affected systems through vendor-supported kernel updates and reboot to ensure the fixed kernel is active.
• Prioritize mobile endpoints, embedded Linux devices, and systems where Wi-Fi is operationally important or where local users can influence driver load/unload behavior.
• Temporarily disable the affected wireless driver or hardware on systems that cannot be patched and do not require Realtek Wi-Fi functionality.
• Review kernel logs for historical rtlwifi crashes, KASAN reports, use-after-free messages, or oops traces involving _rtl_pci_prepare_bcn_tasklet and rtl_pci_deinit.
• Restrict the ability to unload kernel modules or manipulate PCI devices to trusted administrators only.
• Track distribution advisories because exact fixed kernel package versions vary by vendor and kernel branch.