CVE-2024-50288

What it actually does

Out-of-bounds write to the must_blank array sized for 32 entries (VIDEO_MAX_FRAME) when the video capture queue accepts up to 64 buffers, allowing writes at indices >=32.

Why it matters to the business

Kernel crashes or potential privilege escalation on systems using the vivid driver, leading to downtime and possible full system compromise in media or testing workloads.

How an attack unfolds

An attacker interacts with the vivid video capture device and requests buffer counts exceeding 32, causing the driver to index past the end of the undersized must_blank array and overwrite adjacent kernel memory.

How to fix it

Apply the kernel patch that introduces MAX_VID_CAP_BUFFERS, resizes the must_blank array, and correctly sets max_num_buffers for the video capture queue; rebuild and deploy the updated kernel.

How to confirm the fix worked

Confirm the patched kernel defines MAX_VID_CAP_BUFFERS and allows allocation of 64 buffers without oops; review dmesg for vivid-related buffer errors on test systems.

Typical attack path

1. Locate a system exposing the vivid video capture interface
2. Open the device and request more than 32 buffers on the capture queue
3. Trigger buffer allocation that indexes the undersized array
4. Overwrite kernel memory to induce crash or gain code execution

How to detect it

Search kernel logs for vivid-related oops, warnings about buffer indices, or must_blank array accesses; monitor for unusual video device open patterns from untrusted processes.

What your security team should do

• Prioritize kernel updates on systems exposing vivid or similar media drivers
• Restrict untrusted access to /dev/video* nodes until patched
• Audit custom media applications for buffer count assumptions