CVE-2026-43293: Linux Kernel Race Condition Vulnerability

CVE-2026-43293 Overview

CVE-2026-43293 is a race condition vulnerability in the Linux kernel's chips-media: wave5 video processing unit (VPU) driver. The flaw exists in the driver's polling mode cleanup logic, where kthread_destroy_worker() is called before hrtimer_cancel(). This ordering allows the high-resolution timer to fire during worker destruction and queue new work via kthread_queue_work(), triggering WARN_ON assertions in kernel/kthread.c. The condition reliably reproduces on every module unload in polling mode (when irq < 0), producing kernel warnings and potential availability impact on affected systems.

Critical Impact
A local low-privileged user able to unload the wave5 kernel module can trigger kernel warnings and disrupt media subsystem availability through the race between hrtimer callbacks and kthread worker destruction.

Affected Products

Linux Kernel — wave5 media driver (drivers/media/platform/chips-media/wave5)
Systems using the Chips&Media WAVE5 VPU in polling mode (where irq < 0)
Multiple stable Linux kernel branches receiving the backported fix

Discovery Timeline

2026-05-08 - CVE-2026-43293 published to NVD
2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-43293

Vulnerability Analysis

The wave5 driver supports two operating modes: interrupt-driven and polling. In polling mode, the driver uses an hrtimer to periodically invoke wave5_vpu_timer_callback(), which queues deferred work onto a kthread worker using kthread_queue_work(). The cleanup path in wave5_vpu_remove() invoked kthread_destroy_worker() before cancelling the timer with hrtimer_cancel().

This ordering created a Time-of-Check Time-of-Use (TOCTOU) style race. kthread_destroy_worker() validates that both worker->work_list and worker->delayed_work_list are empty using WARN_ON(!list_empty(...)). If the hrtimer fired between the emptiness check and worker teardown, the callback would enqueue new work and trip the assertion. The vulnerability is categorized under [NVD-CWE-noinfo] but represents a classic race condition in kernel resource teardown.

Root Cause

The root cause is incorrect cleanup ordering in the driver's remove callback. The hrtimer must be cancelled before the kthread worker is destroyed, otherwise the timer remains an active producer of work items targeting a worker that is being torn down. The fix reverses the order, calling hrtimer_cancel() first to guarantee both work queues remain empty during destruction.

Attack Vector

Exploitation requires local access with privileges sufficient to unload the wave5 kernel module (typically CAP_SYS_MODULE). The bug does not yield code execution or information disclosure. Repeated module load and unload cycles in polling mode reliably trigger the WARN_ON, producing kernel log noise and, depending on panic_on_warn configuration, a kernel panic resulting in denial of service.

No public exploit code or proof-of-concept is available for this issue. The vulnerability manifests deterministically during module removal when the driver operates without a hardware IRQ.

Detection Methods for CVE-2026-43293

Indicators of Compromise

Kernel log entries containing WARNING: CPU: ... at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98
Call traces referencing wave5_vpu_remove and platform_remove during module unload
Repeated WARN_ON(!list_empty(&worker->work_list)) assertions correlated with wave5 module activity
Unexpected kernel panics on systems configured with panic_on_warn=1 and the wave5 driver loaded

Detection Strategies

Parse dmesg and journalctl -k output for the specific stack trace involving kthread_destroy_worker and wave5_vpu_remove
Inventory hosts running kernels predating commits 0c2e752688a0, 156020e889ed, 5a0c122e834b, and cc8071b1bac6
Monitor module load and unload events for wave5 via auditd rules on init_module and delete_module syscalls

Monitoring Recommendations

Forward kernel logs to a centralized log platform and alert on the kthread_destroy_worker warning signature
Track kernel version inventory across Linux fleets to identify hosts missing the stable backports
Restrict CAP_SYS_MODULE to a minimal set of administrative accounts and audit its use

How to Mitigate CVE-2026-43293

Immediate Actions Required

Apply the upstream stable kernel updates containing the cleanup ordering fix for the wave5 driver
Restrict module unload privileges by limiting CAP_SYS_MODULE and disabling unprivileged module operations where feasible
If the wave5 VPU driver is not required, blacklist the module to eliminate the attack surface
Avoid panic_on_warn=1 on production systems where the warning could be triggered before patching

Patch Information

The fix reorders the cleanup sequence in wave5_vpu_remove() so that hrtimer_cancel() runs before kthread_destroy_worker(). The patch has been merged across stable trees in the following commits: 0c2e752688a0, 156020e889ed, 5a0c122e834b, and cc8071b1bac6. Rebuild and reboot affected hosts after applying the kernel update.

Workarounds

Blacklist the wave5 module via /etc/modprobe.d/blacklist-wave5.conf on systems that do not require VPU functionality
Operate the driver in interrupt mode (ensure a valid IRQ is provisioned) to avoid the polling-mode cleanup path entirely
Avoid unloading the wave5 module on production systems until the kernel patch is applied

bash

# Configuration example: blacklist the vulnerable driver until patched
echo 'blacklist wave5' | sudo tee /etc/modprobe.d/blacklist-wave5.conf
sudo depmod -a
sudo update-initramfs -u
# Verify the module is not loaded after reboot
lsmod | grep wave5