CVE-2024-27072

What it actually does

The flaw consists of unnecessary locking calls inside usbtv_video_free() that can be reached during device unregister; these locks create a deadlock condition when the function is invoked from certain contexts, including non-streaming disconnects after commit c838530d230b.

Why it matters to the business

Linux systems that use usbtv USB video capture hardware can experience sudden kernel deadlocks, forcing reboots and interrupting any media ingestion workloads that rely on the device.

How an attack unfolds

A local attacker attaches or detaches a usbtv device (or triggers its removal via syzkaller-style fuzzing); the resulting call path executes the flawed locking sequence in usbtv_video_free(), deadlocking the kernel regardless of whether streaming was active.

How to fix it

Upgrade the Linux kernel to the commit 4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9 (or an equivalent stable backport) that removes the useless locks and the redundant usbtv_stop() call from usbtv_video_free().

How to confirm the fix worked

Confirm the running kernel contains commit 4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9, then exercise device attach/detach and streaming start/stop sequences while monitoring for deadlock symptoms.

Typical attack path

1. Obtain local access on a system with the usbtv driver loaded
2. Trigger device connect or disconnect events
3. Invoke usbtv_video_free() through normal unregister paths
4. Induce the deadlock condition via the retained lock calls

How to detect it

Inspect kernel logs and crash dumps for deadlock traces involving usbtv_video_free or usbtv_stop after device removal events; correlate with USB subsystem activity around the same timestamp.

What your security team should do

• Apply the referenced kernel commit or a later distribution update as soon as possible
• Restrict unprivileged access to USB devices on systems that expose the usbtv driver
• Include usbtv-related deadlock signatures in kernel oops monitoring