CVE-2024-36976

What it actually does

The change introduced inverted lock acquisition order between two v4l2 control handler locks, creating a classic ABBA deadlock on the vivid driver control structures during concurrent status logging and control operations.

Why it matters to the business

Systems running affected kernels may experience kernel deadlocks when media capture or video4linux applications are active, resulting in system hangs, loss of media functionality, and unplanned downtime until reboot.

How an attack unfolds

An attacker or even a local unprivileged process triggers the deadlock by performing simultaneous v4l2 control status queries and control updates that acquire the two handlers' locks in opposite order; no special privileges beyond access to the vivid or similar v4l2 device nodes are required.

How to fix it

Upgrade the Linux kernel to version 6.9.2 or later, or apply the revert commit 2e0ce54a9c5c7013b1257be044d99cbe7305e9f1 in custom builds; disable unnecessary v4l2 devices and media applications until patched.

How to confirm the fix worked

Confirm the running kernel contains the revert commit or is at least 6.9.2; exercise concurrent v4l2 status and control operations under load to verify absence of deadlock warnings in dmesg or lockdep reports.

Typical attack path

1. Obtain local access or run code that can open /dev/video* or equivalent v4l2 device nodes
2. Issue VIDIOC_LOG_STATUS or equivalent control queries while another thread or process modifies controls on the same handler
3. Trigger the inverted lock acquisition sequence that leads to deadlock
4. Kernel threads hang, causing system-wide impact until manual intervention

How to detect it

Search kernel logs for lockdep warnings containing vivid_ctrls, hdl_vid_cap, or hdl_user_vid; look for processes stuck in v4l2 control handler paths during media workloads.

What your security team should do

• Prioritize kernel upgrades to 6.9.2+ on all systems exposing v4l2 or media devices
• Review and restrict access to video4linux device nodes via udev or AppArmor/SELinux policies
• Monitor for kernel lockdep warnings mentioning hdl_vid_cap or hdl_user_vid after patching