CVE-2024-53104

What it actually does

This is a Linux kernel memory-corruption flaw in the uvcvideo driver. When parsing USB Video Class streaming descriptors, uvc_parse_format() did not account for frames of type UVC_VS_UNDEFINED when sizing the frames buffer, but later parsing could still process those frames. A crafted UVC device or equivalent local trigger can therefore cause out-of-bounds writes in kernel memory. Successful exploitation can allow a local attacker to escalate privileges to kernel/root level, corrupt kernel memory, crash the host, or potentially bypass isolation boundaries that depend on the kernel. The supplied affected-product metadata references OpenSSL packages, which does not align with the kernel uvcvideo vulnerability; remediation should be validated against the Linux kernel package/build actually in use.

Why it matters to the business

An attacker who already has local execution or can cause a malicious video device to be parsed by the host may be able to take full control of the system. This can lead to data theft, tampering, disabling of security tools, container or workload escape depending on deployment, and unplanned outages from kernel crashes. Because this issue is in CISA KEV, is marked active in the wild, and the KEV remediation deadline was 2025-02-26, unpatched systems should be treated as overdue and high priority even though the EPSS score is relatively low.

How an attack unfolds

An attacker first gains local code execution, interactive access, or an opportunity to attach or emulate a malicious USB Video Class device. They then present crafted UVC descriptors containing frame entries of type UVC_VS_UNDEFINED that cause the uvcvideo parser to miscalculate the required frame buffer size. When the kernel parses the malformed streaming format, writes can occur past the end of the allocated frames array. With a reliable exploit, the attacker shapes the corrupted kernel memory to overwrite security-relevant structures or control data, resulting in privilege escalation to root or kernel-level execution. Less reliable attempts may produce kernel warnings, oopses, device enumeration failures, or host crashes. Public reporting and KEV status indicate exploitation activity in the wild, including broader Linux kernel privilege-escalation activity and zero-day exploitation campaigns, so defenders should assume exploit attempts may be chained after initial access.

How to fix it

Apply the vendor-supported Linux kernel update that contains the uvcvideo fix for this issue. Prioritize laptops, workstations, developer systems, kiosks, virtualization hosts, and servers where USB passthrough, webcams, media capture devices, or untrusted local users are present. Reboot after updating so the fixed kernel is running; merely installing the package is insufficient if the vulnerable kernel remains booted. If immediate patching is not possible, reduce exposure by disabling or blacklisting the uvcvideo module where webcams are not required, restricting physical USB access, disabling USB passthrough to guests, limiting local shell access, and enforcing device-control policies. Example mitigations include unloading the module with modprobe -r uvcvideo where safe and preventing reload via a modprobe blacklist, but these should be tested because they may break camera functionality. The provided fixed-version data lists OpenSSL versions for Ubuntu 14.04 and 16.04, which appears inconsistent with this kernel flaw and should not be relied on as proof of remediation for this vulnerability.

How to confirm the fix worked

Confirm that systems are running a kernel build from the OS vendor that includes the uvcvideo patch, not just that updates are installed. Validate with uname -a, package-manager kernel version queries, and vendor advisory mapping for the running kernel. Check whether the uvcvideo module is present or loaded using lsmod, modinfo uvcvideo, or /sys/module/uvcvideo. If mitigation rather than patching is used, confirm that uvcvideo cannot be loaded and that required camera workflows still behave as expected. Review boot history to ensure hosts have restarted into the fixed kernel. For high-assurance validation, test with a non-production system by verifying that malformed UVC descriptors no longer trigger kernel warnings, KASAN reports, oopses, or crashes.

Typical attack path

1. Obtain local execution on a Linux system or physical/virtual ability to present a USB Video Class device to the host.
2. Ensure the uvcvideo kernel module is loaded or trigger autoloading by connecting/emulating a UVC device.
3. Present crafted UVC streaming descriptors containing UVC_VS_UNDEFINED frame types.
4. Trigger uvc_parse_format() during device enumeration or video-device initialization.
5. Cause an out-of-bounds kernel memory write due to incorrect frame-buffer sizing.
6. Use the memory corruption primitive to crash the system or escalate privileges to root/kernel context.
7. Disable defenses, access sensitive data, move laterally, or persist using the newly elevated privileges.

How to detect it

There is no single reliable forensic indicator for successful exploitation because the core issue is kernel memory corruption. Review kernel logs, system journals, audit logs, EDR telemetry, and USB/device-management logs for suspicious UVC device enumeration, unexpected loading of the uvcvideo module, kernel oopses or crashes during camera/device initialization, and KASAN or slab out-of-bounds reports referencing uvc_parse_format or uvcvideo. Correlate these events with local logins, newly created users, privilege changes, sudo activity, unusual root shells, kernel module loading, security-tool stoppage, or persistence creation. On systems with USB passthrough or virtual USB gadget support, review hypervisor, container, and host logs for newly attached video devices or unexpected USB redirection. Because exploitation has been observed in the wild, also hunt for broader post-exploitation activity after suspicious uvcvideo events, including credential dumping, lateral movement tooling, modified SSH authorized_keys files, new setuid binaries, and unexplained kernel crashes or reboots.

• uvcvideo
• uvc_parse_format
• UVC_VS_UNDEFINED
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in uvc_parse_format
• general protection fault
• Oops: 0000
• kernel NULL pointer dereference
• new high-speed USB device
• new SuperSpeed USB device
• USB Video Class device
• Found UVC
• modprobe uvcvideo
• /sys/module/uvcvideo
• /lib/modules/*/kernel/drivers/media/usb/uvc/uvcvideo.ko
• uvcvideo: Failed to query
• uvcvideo: Unable to create debugfs directory

What your security team should do

• Treat this as urgent for Linux endpoints and hosts with USB/video exposure because it is KEV-listed, exploited in the wild, and past the 2025-02-26 CISA due date.
• Inventory Linux systems with the uvcvideo module available or loaded, especially workstations, laptops, VDI endpoints, lab systems, and hosts allowing USB passthrough.
• Patch affected Linux kernels and reboot into the fixed kernel; verify the running kernel version after reboot.
• Temporarily disable or blacklist uvcvideo on systems that do not require webcam or UVC device support.
• Restrict untrusted physical USB access and disable USB passthrough from untrusted devices into virtual machines or containers where feasible.
• Hunt for kernel oopses, KASAN slab out-of-bounds reports, unexpected uvcvideo module loads, and suspicious USB video-device enumeration around times of local account activity.
• Do not use the listed OpenSSL package versions as remediation evidence for this kernel vulnerability; reconcile asset data against authoritative Linux kernel advisories.
• Increase monitoring for post-exploitation behavior such as new root-level processes, suspicious setuid files, kernel module changes, credential access, and security-tool tampering.