CVE-2026-68214
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A driver bug in Linux can let a timer keep running after the driver is removed, which may crash the system or let an attacker gain more control.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Use-after-free in rtl2832_remove() caused by calling cancel_delayed_work_sync() before i2c_mux_del_adapters(), allowing rtl2832_deselect() to reschedule i2c_gate_work after cancellation but before kfree(dev).
Why it matters to the business
Kernel module unloading during active I2C operations on supported tuners can trigger crashes or memory corruption, leading to system instability and potential local privilege escalation on affected Linux systems.
How an attack unfolds
An attacker with local access loads the rtl2832 driver, initiates I2C transfers through the mux adapter during probe or runtime, then triggers driver removal while a transfer is in flight so that rtl2832_deselect() reschedules the delayed work after it has been cancelled, resulting in use-after-free on subsequent kfree.
How to fix it
Apply the upstream fix that reorders the calls to perform i2c_mux_del_adapters() before cancel_delayed_work_sync() in rtl2832_remove(). Rebuild and install the patched kernel module, then reboot or reload the driver.
How to confirm the fix worked
Confirm the source change moves i2c_mux_del_adapters() ahead of cancel_delayed_work_sync() in rtl2832_remove(), then verify no delayed work can be rescheduled after mux unregistration by reviewing the updated probe/remove sequence.
Typical attack path
- Load rtl2832 kernel module on system with compatible hardware
- Trigger I2C transfers via r820t_attach or similar during probe
- Concurrently invoke rtl2832_remove while transfer is still in flight
- rtl2832_deselect reschedules i2c_gate_work after cancel_delayed_work_sync
- kfree(dev) executes with active timer leading to use-after-free
How to detect it
Review kernel logs for oops or use-after-free warnings referencing rtl2832, i2c_gate_work, or rtl2832_remove during module unload; correlate with dmesg entries showing concurrent I2C mux activity.
What your security team should do
- Prioritize kernel update containing the reorder fix for any systems using rtl2832-based DVB tuners
- Monitor for driver unload events on production media systems
- Test driver removal under load in staging environments before deploying broadly
The record
In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|