CVE-2024-53104 - Out of Bounds Write in Linux Kernel UVC Video Driver (`uvcvideo`) Explained

A newly patched vulnerability, CVE-2024-53104, was found in the Linux kernel's USB Video Class (UVC) driver, specifically affecting the way video frame data is processed. Attackers could exploit this flaw to cause an out of bounds write, resulting in possible kernel crashes, information leaks, or even privilege escalation. This post breaks down how the bug works, walks through the vulnerable code, shows a basic proof-of-concept, and summarizes the fix—using straightforward language for Linux users and developers.

What’s the Problem?

The *UVC Video driver* allows USB webcams and video devices to communicate with the Linux kernel. Inside the file uvc_video.c, the function uvc_parse_format() did not properly skip video frames classified as UVC_VS_UNDEFINED.

If an attacker plugs in (or emulates) a malicious USB webcam that reports an undefined video frame, the kernel would miscalculate the amount of data required for frame parsing and then write beyond the memory buffer. This "out of bounds" write could corrupt memory and allow for further attacks.

Let’s look at the relevant code section (simplified for clarity)

// Linux kernel: drivers/media/usb/uvc/uvc_video.c

static int uvc_parse_format(struct uvc_streaming *stream, ...)
{
    // For every video frame descriptor
    for (i = ; i < num_frames; ++i) {
        struct uvc_frame_desc *desc = ...; // Frame descriptor from the USB device

        /* PROBLEM: The original code did not check for UVC_VS_UNDEFINED here */

        // Parse the frame entry, and add it to the buffer
        uvc_parse_frame(stream, desc, ...);
    }
}

The *missing check* meant that undefined frames were counted like ordinary ones. When the kernel calculated how much space it needed for all frames, it didn't account for extra undefined frame types, resulting in writing past the end of the buffer if one popped up.

How the Patch Fixes It

The security patch adds a check to skip frames of type UVC_VS_UNDEFINED—thus, the buffer only gets as big as it needs to be, and no out of bounds writes can occur.

Patched code snippet

if (desc->bDescriptorSubType == UVC_VS_UNDEFINED) {
    // Ignore undefined frame types
    continue;
}

See the patch in kernel.org git for full details.

Custom or Malicious Webcam Device:

An attacker creates or modifies a USB webcam (hardware or emulated, e.g., using USB/IP or a Raspberry Pi) to send UVC descriptors with undefined frame types.

Trigger the Kernel Bug:

The fake frame data forces the Linux kernel to write past the allocated buffer when it parses the streaming format.

*Privilege Escalation*: Less likely, but possible with further exploitation.

A basic proof-of-concept of a malicious device could look like this pseudocode (for a USB gadget or fuzzing tool):

# This is schematic; actual USB protocol work is more involved.

uvc_frame_desc = {
    'bLength': 26,
    'bDescriptorType': USB_DT_CS_INTERFACE,
    'bDescriptorSubType': UVC_VS_UNDEFINED,   # <= Key part!
    # ... the rest of the fields don't matter
}

# Device sends this descriptor when the host queries frames

You would use tools like Facedancer or LUK to actually craft and inject such UVC frames.

Upgrade Your Kernel!

Upstream patch landed in Linux during May/June 2024. Distros will pick it up in regular updates. Most users should be safe if running kernel 6.9 or newer, or after your distribution backports the patch.

Upstream Patch:

kernel/git/torvalds/linux.git - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format

CVE Record:

CVE-2024-53104 at MITRE (TBA)

Linux UVC Project:

Linux UVC driver & tools

USB Video Class Specification:

USB.org UVC Spec PDF

Conclusion

While issues like CVE-2024-53104 are mostly theoretical for everyday users, they remind us how subtle USB device bugs can sneak security holes into the Linux kernel. If you regularly use USB webcams or work in environments where USB devices can be plugged in, be sure to keep your systems updated. Kudos to the Linux kernel contributors who fixed this fast!

Timeline

Published on: 12/02/2024 08:15:08 UTC
Last modified on: 01/20/2025 06:19:37 UTC