CVE-2026-46187

What it actually does

This vulnerability is a race condition in the Linux kernel RSI wireless driver thread shutdown logic. The driver can attempt to stop a kernel thread with kthread_stop() after that same thread has already self-terminated via kthread_complete_and_exit(), causing a use-after-free of the freed kthread object. Successful exploitation is expected to affect availability rather than confidentiality or integrity, most likely by triggering a kernel crash, panic, or system instability. The issue requires local access, low privileges, no user interaction, and a difficult timing condition, which makes exploitation non-trivial but still relevant on systems using the affected RSI Wi-Fi driver.

Why it matters to the business

Affected Linux systems that load or use the RSI wireless driver could be crashed by a local attacker or by a process able to exercise the vulnerable driver path, causing service interruption, device downtime, failed workloads, or operational disruption. The risk is lower than a remote code execution flaw because exploitation requires local access and precise timing, but the impact can still be significant for laptops, embedded systems, wireless gateways, industrial devices, kiosks, or edge systems that depend on wireless connectivity. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS, so remediation should be prioritized based on whether affected RSI hardware or modules are present and whether local untrusted users or workloads exist.

How an attack unfolds

An attacker first needs local execution capability on an affected Linux system where the RSI wireless driver is present and the vulnerable code path can be reached. The attacker then repeatedly triggers driver lifecycle activity that causes an RSI driver kernel thread to exit while another path attempts to stop that same thread. In the vulnerable race window, the thread may self-exit and free its kthread object before the external stop path calls kthread_stop(). That later access to the freed object causes a kernel use-after-free. In practical terms, the most likely attacker objective is denial of service: forcing a kernel crash, panic, watchdog reset, or other instability that interrupts the host or device. There is no public exploit maturity indicated in the supplied data, and exploitation is constrained by high attack complexity and local access requirements.

How to fix it

Update the Linux kernel to a version that includes the upstream RSI driver fix replacing the unsafe external kthread_stop() behavior with waiting for self-exit completion. Because no exact fixed package versions were provided, use the fixed kernel version supplied by the relevant Linux distribution, appliance vendor, or kernel maintainer for CVE-2026-46187. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the affected RSI wireless driver if it is not required, removing unused RSI Wi-Fi hardware support from custom kernels, restricting local shell access to trusted users, and limiting untrusted workloads that can interact with network device lifecycle operations. For embedded or appliance deployments, obtain vendor firmware or kernel updates that incorporate the corrected RSI driver lifetime handling.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or firmware build includes the vendor fix for this issue, not just that an updated package is installed on disk. Check the active kernel with uname -r and compare it against the distribution or vendor advisory. If source validation is possible, confirm the RSI driver no longer calls kthread_stop() on the affected self-exiting thread path and instead waits for completion of the self-exit operation. Confirm whether the RSI driver is present or loaded by checking loaded kernel modules and kernel configuration for RSI wireless support. Where the driver is not needed, validate mitigation by confirming the relevant RSI modules cannot be loaded and are not present in lsmod output after reboot. Functional validation should include wireless interface lifecycle testing, suspend/resume if applicable, and repeated driver unload/reload testing in a controlled environment while monitoring dmesg for kernel warnings, use-after-free reports, or panics.

Typical attack path

1. Obtain local execution on a Linux system running an affected kernel and using or loading the RSI Wi-Fi driver.
2. Confirm that RSI wireless kernel modules or related hardware support are present.
3. Repeatedly exercise driver start, stop, teardown, suspend/resume, interface reset, module unload, or device removal paths to increase the chance of hitting the race condition.
4. Cause the RSI driver worker thread to self-exit while another control path attempts to stop the same thread externally.
5. Trigger use-after-free access to the already-freed kthread object.
6. Induce kernel instability, crash, panic, reboot, or loss of availability.

How to detect it

To determine whether exploitation or attempted triggering occurred, review kernel logs, persistent journal entries, crash dumps, and endpoint telemetry for RSI wireless driver activity followed by kernel warnings, use-after-free reports, panics, watchdog resets, or unexpected reboots. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel facility logs, kdump/vmcore artifacts, pstore/ramoops logs on embedded systems, and EDR telemetry for module load/unload activity. Focus on events involving RSI Wi-Fi modules, interface resets, suspend/resume cycles, device removal, or repeated module unload/reload operations shortly before a crash. If Kernel Address Sanitizer, slab debugging, or hardened allocator telemetry is enabled, search for use-after-free diagnostics referencing kernel threads, kthread_stop, kthread_complete_and_exit, or RSI driver functions. Absence of logs does not rule out exploitation because a kernel crash can prevent log flushing; persistent crash storage such as kdump, pstore, or remote syslog improves confidence.

• rsi_91x
• rsi_91x_usb
• rsi_91x_sdio
• rsi_usb
• rsi_sdio
• RSI
• kthread_stop
• kthread_complete_and_exit
• use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• Unable to handle kernel paging request
• general protection fault
• Kernel panic
• watchdog: BUG: soft lockup
• watchdog: hard LOCKUP
• /var/crash/
• /sys/fs/pstore/
• /proc/modules
• modprobe rsi_91x
• modprobe -r rsi_91x
• rmmod rsi_91x

What your security team should do

• Inventory Linux systems, embedded devices, wireless appliances, and custom kernel builds to identify those with RSI Wi-Fi driver support enabled or loaded.
• Prioritize patching systems where RSI wireless hardware is used, local users are untrusted, container workloads are allowed broad host interaction, or device availability is operationally critical.
• Apply the kernel, firmware, or vendor appliance update that contains the RSI driver kthread lifetime fix.
• If patching is delayed and RSI Wi-Fi is not required, blacklist or disable the affected RSI driver modules and reboot to confirm they remain unloaded.
• Restrict local interactive access and privileged device-management capabilities on affected systems until patched.
• Monitor kernel logs for crashes, use-after-free reports, RSI driver errors, unexpected reboots, and module unload/load activity involving RSI wireless components.
• For custom kernels, backport the upstream fix and rebuild with the corrected driver logic or disable RSI driver support if unused.
• Because this issue is not KEV-listed, not known ransomware-used, and has low EPSS, treat it as targeted availability risk rather than broad internet-exploitation risk, but do not ignore it on exposed multi-user or high-availability systems.