CVE-2026-89899: Linux Kernel Media CEC Use-After-Free Vulnerability

CVE-2026-89899 Overview

CVE-2026-89899 is a use-after-free race condition in the Linux kernel's Consumer Electronics Control (CEC) media subsystem. The flaw resides in cec_transmit_msg_fh(), which drops adap->lock while waiting for a blocking transmit through wait_for_completion_killable(). When a signal interrupts that wait, cancel_delayed_work_sync() can execute before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) inside cec_transmit_done_ts(). The freed data structure retains a pending delayed work reference, producing an ODEBUG warning and a memory-safety violation. Local authenticated attackers can leverage this window to trigger memory corruption in kernel space, threatening confidentiality, integrity, and availability of the host.

Critical Impact
A local attacker with low privileges can trigger a use-after-free in the CEC subsystem, enabling potential kernel memory corruption and privilege escalation on affected Linux systems.

Affected Products

Linux kernel media subsystem (drivers/media/cec)
Distributions shipping vulnerable stable kernel branches referenced in the upstream commits
Systems exposing CEC device nodes (typically HDMI-capable hardware and embedded platforms)

Discovery Timeline

2026-09-16 - CVE-2026-89899 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89899

Vulnerability Analysis

The vulnerability is a race condition in the CEC transmit path that leads to a use-after-free [CWE-416]. cec_transmit_msg_fh() releases adap->lock so the caller can block on wait_for_completion_killable(). If a signal interrupts that wait, the caller proceeds to clean up the transmit structure. Concurrently, the CEC kthread may still call cec_transmit_done_ts(), which arms a reply timeout via schedule_delayed_work(&data->work). When cleanup runs cancel_delayed_work_sync() before the kthread arms the work, the delayed work is scheduled after cancellation. The transmit data is then freed while cec_wait_timeout is still pending on the workqueue.

The ODEBUG subsystem detects this condition and reports: ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout. Once the timer fires against freed memory, kernel state becomes corruptible.

Root Cause

The root cause is an ordering flaw between signal-driven cancellation and asynchronous scheduling of a delayed work item. cancel_delayed_work_sync() cancels only work that is currently pending or running. It does not prevent later schedule_delayed_work() calls from re-arming the same work. Because the lock is dropped during the wait, the kthread can arm the timeout after the cancel completes, leaving a live workqueue reference to about-to-be-freed memory.

The fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync(), which cancels the work and disables further scheduling. Subsequent schedule_delayed_work() calls become no-ops, and the freed data cannot be re-armed.

Attack Vector

Exploitation requires local access with the ability to open a CEC character device and issue transmit ioctls. An attacker races a blocking transmit against signal delivery to interrupt wait_for_completion_killable() at a precise moment. Repeated attempts on multi-core systems increase the probability of hitting the race window. Successful triggering yields a use-after-free on kernel heap memory associated with the CEC transmit data.

Refer to the upstream fix commits for exact patched call paths: Kernel commit 0fbd5c23, commit 9a951931, commit 9c6ceb09, and commit a3adb63b.

// No verified proof-of-concept is public. See upstream commits for the fix.

Detection Methods for CVE-2026-89899

Indicators of Compromise

Kernel log entries containing ODEBUG: free active (active state 0) object with the hint cec_wait_timeout.
Unexpected kernel oops or general protection faults referencing cec_wait_timeout or delayed_work_timer_fn in the call trace.
Repeated open/ioctl activity against /dev/cec* character devices from non-privileged processes.

Detection Strategies

Enable CONFIG_DEBUG_OBJECTS and CONFIG_DEBUG_OBJECTS_WORK on test kernels to surface the ODEBUG warning that identifies the race.
Monitor dmesg and journald for KASAN or use-after-free reports referencing the CEC subsystem.
Correlate CEC ioctl telemetry with signal delivery patterns to identify processes attempting to race the transmit path.

Monitoring Recommendations

Ingest kernel ring buffer output into a centralized log pipeline and alert on ODEBUG, KASAN, and use-after-free strings.
Track process access to /dev/cec* devices, particularly from low-privileged accounts on servers without HDMI use cases.
Baseline CEC ioctl volume per host and alert on statistically anomalous bursts consistent with race exploitation attempts.

How to Mitigate CVE-2026-89899

Immediate Actions Required

Update to a stable Linux kernel version containing the upstream fix commits referenced by CVE-2026-89899.
Where patching is delayed, restrict access to /dev/cec* device nodes to trusted administrative users only.
Audit which systems expose CEC devices and disable the cec kernel module on hosts that do not require it.

Patch Information

The upstream fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync() in the CEC transmit cleanup path. Apply the changes from Kernel commit 0fbd5c23, commit 9a951931, commit 9c6ceb09, and commit a3adb63b, or install vendor kernel packages incorporating these patches.

Workarounds

Blacklist the cec module using modprobe.d configuration on systems that do not need CEC functionality.
Tighten permissions on /dev/cec* nodes via udev rules so only root or a dedicated group can open them.
Apply MAC policies (SELinux, AppArmor) that deny non-privileged processes access to CEC character devices.

bash

# Configuration example: block the cec module and restrict device access
echo "blacklist cec" | sudo tee /etc/modprobe.d/disable-cec.conf
sudo depmod -a

# udev rule to restrict CEC device access to root only
echo 'KERNEL=="cec[0-9]*", MODE="0600", OWNER="root", GROUP="root"' | \
  sudo tee /etc/udev/rules.d/90-cec-restrict.rules
sudo udevadm control --reload-rules && sudo udevadm trigger