CVE-2026-89899: media: cec: disable delayed work before freeing an interrupted transmit
In the Linux kernel, the following vulnerability has been resolved:
media: cec: disable delayed work before freeing an interrupted transmit
cectransmitmsgfh() drops adap->lock to wait for a blocking transmit in waitforcompletionkillable(). If that wait is interrupted by a signal, canceldelayedworksync() can run before the CEC kthread arms the reply timeout via scheduledelayedwork(&data->work) in cectransmitdonets(). The work is then armed after the cancel, and the data is freed with its delayedwork still pending:
ODEBUG: free active (active state 0) object: ... hint: cecwaittimeout
Use disabledelayedworksync(): it cancels the work and disables it, so the later scheduledelayedwork() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.
Event History
Frequently Asked Questions
What conditions are required to trigger the vulnerable path?
A blocking CEC transmit must be waiting in cec_transmit_msg_fh(), and that wait must be interrupted by a signal. A timing race is then required: the cancellation occurs before the CEC kernel thread arms the reply-timeout delayed work.
What is the consequence of winning the race?
The transmit data can be freed while its delayed_work remains pending. When that delayed work later runs, it can access freed data.
How is the issue corrected?
The fix uses disable_delayed_work_sync() rather than cancel_delayed_work_sync(). This both cancels the work and prevents the later schedule_delayed_work() call from re-arming it before the associated data is freed.