high CVSS 7.8 Actively exploited

CVE-2024-53104·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.

Severity
high
Software
Kernel
Fixed in
6.12.1
Published
2024-12-02

Affected versions

From: 6.12

Until: 6.12.1

Fixed in: 6.12.1

How to fix this CVE

Update the Linux kernel to version 6.12.1 or later, which adds a check to skip frames of type UVC_VS_UNDEFINED during format parsing. If an immediate kernel update is not feasible, disable the uvcvideo kernel module to eliminate the attack surface entirely. Organizations should also enforce USB device policies to prevent unauthorized peripherals from being connected to servers.

# Check current kernel version
uname -r

# Update package lists and install latest kernel
sudo apt update && sudo apt upgrade -y linux-image-generic linux-headers-generic

# If running HWE kernel (common on Ubuntu LTS)
sudo apt install --install-recommends linux-generic-hwe-$(lsb_release -rs) -y

# Reboot to load the patched kernel
sudo reboot

# After reboot, verify the new kernel is loaded
uname -r

# Temporary mitigation: disable UVC driver without reboot
sudo modprobe -r uvcvideo
echo 'blacklist uvcvideo' | sudo tee /etc/modprobe.d/blacklist-uvcvideo.conf

Defensia detects this vulnerability

What an exploitation attempt looks like

Sample log line indicative of exploitation attempts:

This vulnerability is exploited through the USB physical access vector. An attacker must connect a malicious USB device (or compromise an existing USB peripheral) that presents itself as a UVC-compliant video device. The crafted device sends specially formed USB video streaming descriptors containing frames with type UVC_VS_UNDEFINED (value 0x00). During enumeration, the kernel's uvc_parse_streaming function calculates a buffer size that does not account for these undefined frame types, but uvc_parse_format then attempts to write data for them, causing a heap buffer overflow. This is a local privilege escalation path: an attacker with physical access to a USB port can achieve arbitrary kernel memory writes, leading to full root compromise. The attack has been observed in targeted surveillance operations where a seemingly innocuous USB device is connected to a target machine.

WAF mitigation (if patching is not yet possible)

Add this rule to your WAF to block exploitation attempts while you schedule the patch.

A Web Application Firewall cannot mitigate CVE-2024-53104. This vulnerability operates entirely within the Linux kernel's USB subsystem and does not involve any network traffic, HTTP requests, or web application layer interaction. The attack vector is physical access via USB, which is outside the scope of any network-based security control.

Recommended compensating controls:
- Enforce USB device authorization policies using USBGuard (usbguard daemon) to whitelist only known devices
- Disable the uvcvideo kernel module on servers that have no legitimate need for USB cameras
- Implement physical security controls to restrict USB port access on production servers
- Enable kernel lockdown mode (integrity or confidentiality) to limit kernel module loading
- Use grsecurity or SELinux policies to restrict device enumeration capabilities
- Monitor dmesg and kernel logs for unexpected USB device enumeration events

How to check if you are affected

  1. { "step": 1, "title": "Check if the vulnerable kernel module is loaded", "command": "lsmod | grep uvcvideo", "description": "If the uvcvideo module is loaded, the system has an active attack surface for this CVE. Servers typically should not have this module loaded unless they use USB webcams." }
  2. { "step": 2, "title": "Verify current kernel version against patched versions", "command": "uname -r", "description": "Compare the running kernel version against the fixed version 6.12.1+. Note that many distributions backport fixes, so also check your distro's security advisory for the specific package version that includes the patch." }
  3. { "step": 3, "title": "Check installed kernel packages for patch status", "command": "apt list --installed 2>/dev/null | grep linux-image || rpm -qa | grep kernel-core", "description": "List installed kernel packages to determine whether a patched version has been installed. Cross-reference the package version with your distribution's CVE tracker for CVE-2024-53104." }
  4. { "step": 4, "title": "Audit recent USB device connections in kernel logs", "command": "dmesg | grep -iE 'usb|uvc' | tail -30", "description": "Review kernel messages for any unexpected USB device enumeration events. Look for UVC devices that should not be present on a server, which could indicate an exploitation attempt." }
  5. { "step": 5, "title": "Check systemd journal for USB events over the past week", "command": "journalctl -k --since '7 days ago' | grep -iE 'new (usb|high speed|full speed|low speed)' | tail -20", "description": "Search the persistent journal for USB device connection events that may have occurred outside the current boot's dmesg buffer. Unexpected USB enumerations on headless servers warrant investigation." }
  6. { "step": 6, "title": "Verify USB device authorization policy", "command": "cat /sys/bus/usb/devices/usb*/authorized_default 2>/dev/null; systemctl is-active usbguard 2>/dev/null || echo 'USBGuard not installed'", "description": "Check whether USB device authorization is configured. A value of 1 for authorized_default means all USB devices are automatically authorized, increasing risk. USBGuard provides granular device-level control." }
  7. { "step": 7, "title": "Scan for signs of kernel memory corruption", "command": "dmesg | grep -iE 'BUG|KASAN|slab-out-of-bounds|heap-buffer-overflow|general protection fault' | tail -20", "description": "Check kernel ring buffer for memory corruption indicators. KASAN reports or BUG entries related to slab/heap overflows near UVC code paths could indicate exploitation attempts." }

Indicators of compromise

  • { "type": "kernel_log", "value": "uvcvideo: Found UVC format with unexpected frame type", "description": "Kernel log entry indicating the UVC driver encountered a frame with an undefined type during device enumeration" }
  • { "type": "kernel_log", "value": "slab-out-of-bounds write in uvc_parse_format", "description": "KASAN detection of the heap overflow in the vulnerable function, indicating active exploitation" }
  • { "type": "kernel_log", "value": "BUG: unable to handle page fault in uvc driver", "description": "Kernel page fault in UVC driver code paths, which may indicate memory corruption from exploitation" }
  • { "type": "device_event", "value": "USB device with unexpected UVC streaming descriptor type 0x00", "description": "A USB device presenting UVC Video Streaming descriptors with frame type 0x00 (UVC_VS_UNDEFINED)" }
  • { "type": "module_load", "value": "uvcvideo module loaded on headless server", "description": "The UVC video module being loaded on a server with no legitimate camera use is suspicious and warrants investigation" }

FAQ

Can this vulnerability be exploited remotely over the network?

No. CVE-2024-53104 requires physical access to a USB port or the ability to compromise a USB peripheral already connected to the target machine. There is no network-based attack vector. However, in cloud environments, USB passthrough configurations could theoretically extend the attack surface.

Is this vulnerability actively exploited in the wild?

Yes. Google's Threat Analysis Group confirmed CVE-2024-53104 has been used in targeted attacks. The vulnerability was flagged by CISA in their Known Exploited Vulnerabilities catalog and has been linked to surveillance operations where physical access to the target device was available.

Are cloud servers and VPS instances affected?

Cloud VMs typically do not have USB passthrough enabled, which means the uvcvideo module cannot be triggered by external devices. However, the vulnerable code is still present in unpatched kernels. Organizations should still patch to eliminate the vulnerability, as hypervisor escape scenarios or USB passthrough configurations could create exposure.

Does disabling the uvcvideo module fully mitigate the risk?

Yes, blacklisting and unloading the uvcvideo kernel module eliminates the attack surface entirely. Run 'sudo modprobe -r uvcvideo' to unload it immediately, and add 'blacklist uvcvideo' to /etc/modprobe.d/ to prevent it from loading on boot. This is the recommended interim mitigation for servers that do not use USB cameras.

Which kernel versions are affected?

The vulnerability was introduced in the UVC driver and affects kernels up through version 6.12. The fix was applied in version 6.12.1. However, most Linux distributions backport security fixes to their supported kernel versions, so the specific fixed package version varies by distro. Check your distribution's security tracker for the exact patched package.

What is the CVSS score and why is it rated High rather than Critical?

CVE-2024-53104 has a CVSS score of 7.8 (High). Despite enabling arbitrary kernel memory writes and full privilege escalation, it requires local/physical access to exploit, which limits the attack scope compared to remotely exploitable vulnerabilities. The High rating reflects the significant impact (complete system compromise) balanced against the restricted access vector.

Should I prioritize patching this on my web servers?

For internet-facing servers in data centers or cloud environments, this is lower priority than remote code execution vulnerabilities because it requires physical USB access. However, you should still include it in your regular patching cycle. For on-premises servers, co-located hardware, or edge devices with accessible USB ports, treat this as high priority.

Related Kernel CVEs

CVE-2021-47274CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: tracing: Correct the length check which causes memory corruption We've suffered from severe kernel crashes due to memory corruption on our production environment, like, Call Trace: [1640542.554277] general protection fault: 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286 [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) knlGS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Call Trace: [1640542.567009] anon_vma_clone+0x5d/0x170 [1640542.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] do_syscall_64+0x5b/0x1b0 [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang has reproduced it stably on the latest 4.19 LTS. After some debugging, we finally proved that it's due to ftrace buffer out-of-bound access using a debug tool as follows: [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000 [ 86.780806] no_context+0xdf/0x3c0 [ 86.784327] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] fetch_memory_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func+0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] 0xffffffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("tracing: Check length before giving out the filter buffer") adds length check to protect trace data overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent overflow entirely, the length check should also take the sizeof entry->array[0] into account, since this array[0] is filled the length of trace data and occupy addtional space and risk overflow.
CVE-2021-47378CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: destroy cm id before destroy qp to avoid use after free We should always destroy cm_id before destroy qp to avoid to get cma event after qp was destroyed, which may lead to use after free. In RDMA connection establishment error flow, don't destroy qp in cm event handler.Just report cm_error to upper level, qp will be destroy in nvme_rdma_alloc_queue() after destroy cm id.
CVE-2021-47548CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns.
CVE-2024-9194CVSS 9.8Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Linux and Microsoft Windows Octopus Server on Windows, Linux allows SQL Injection.This issue affects Octopus Server: from 2024.1.0 before 2024.1.13038, from 2024.2.0 before 2024.2.9482, from 2024.3.0 before 2024.3.12766.
CVE-2024-0132CVSS 9NVIDIA Container Toolkit 1.16.1 or earlier contains a Time-of-check Time-of-Use (TOCTOU) vulnerability when used with default configuration where a specifically crafted container image may gain access to the host file system. This does not impact use cases where CDI is used. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-53104. Free for 1 server.

Get started free