In early 2024, a security vulnerability (now known as CVE-2024-27001) was discovered and resolved in the Linux kernel’s comedi subsystem, specifically in the vmk80xx USB driver. This long-read explains what went wrong, offers code snippets, references, and discusses the potential for exploit, in clear, simple language.

What’s this Bug About?

The vmk80xx driver in Comedi (a Linux control and measurement device interface) talks to some special USB-based data acquisition hardware.

The problem? Its function for finding USB endpoints—important channels for communication between Linux and your hardware—did not always verify the details of these endpoints correctly. Different hardware models require different types of endpoints (bulk or interrupt), but the checking code could miss the distinction. As a result, the driver might submit the wrong kind of USB request, leading to system warnings or even a kernel panic if panic_on_warn was enabled.

Here’s what you’d see logged if you triggered the bug

usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU:  PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+xc4e/x18c drivers/usb/core/urb.c:503
...
Call Trace:
 <TASK>
 usb_start_wait_urb+x113/x520 drivers/usb/core/message.c:59
 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
 vmk80xx_auto_attach+xa1c/x1a40 drivers/comedi/drivers/vmk80xx.c:818
 comedi_auto_config+x238/x380 drivers/comedi/drivers.c:1067
 usb_probe_interface+x5cd/xb00 drivers/usb/core/driver.c:399
...

This was found by Syzkaller, an automated Linux kernel fuzzer that finds bugs like this by rapid-fire fuzzing of drivers with all kinds of weird data.

“Isn’t this just a warning?”

- If you run with panic_on_warn=1 (for *maximum* kernel paranoia/security), your whole machine can crash.

Even if not, fuzzers and attackers might exploit it to cause denial of service.

- While not a direct privilege escalation, weakening endpoint checks increases unpredictable kernel behavior—never good for security.

How Was It Exploited?

By plugging in a USB device (or using emulation/testing tools) that declares endpoints with a non-standard configuration the driver didn’t expect, you could cause those URBs to be submitted with mismatched types, just as Syzkaller did. This triggers the warning or crash.

A simple proof-of-concept with a fake USB device using USB/IP or gadgetfs could reproduce the condition (crashing or warning) if panic_on_warn is enabled. Here’s a highly simplified illustration:

// NOT a working exploit — just showing how a fuzzed device with mismatched endpoints
// could trip up the old code
struct usb_device *dev = usb_find_device(...);
struct usb_endpoint_descriptor *ep = ...; // bad endpoint type
urb = usb_alloc_urb(, GFP_KERNEL);
urb->pipe = usb_sndbulkpipe(dev, ep->bEndpointAddress); // expects bulk pipe
urb->transfer_buffer = ...;
urb->transfer_buffer_length = ...;

// If ep->bmAttributes is INTERRUPT, but code expects BULK, kernel will warn/crash
usb_submit_urb(urb, GFP_KERNEL);

A user in physical control or with sufficient privileges to add malicious USB devices, or to fuzz USB drivers remotely (as with USB over IP), could trigger this.

The Fix

The kernel patch (see here) simplifies and hardens endpoint selection. The new code uses usb_find_common_endpoints(), a helper that *always* checks for correct endpoint types and numbers, so no wrong combinations slip through:

Fixed Code Snippet

// Before (summary — incomplete checking)
int found_in = , found_out = ;
for (ep = ...; ...; ...) {
    if (usb_endpoint_is_bulk_in(ep))
        found_in++;
    if (usb_endpoint_is_bulk_out(ep))
        found_out++;
}
if (!found_in || !found_out)
    return -ENODEV; // Error

// After (simplified, robust)
struct usb_endpoint_descriptor *bulk_in, *bulk_out;
usb_find_common_endpoints(interface->cur_altsetting, &bulk_in, &bulk_out, NULL, NULL);
if (!bulk_in || !bulk_out)
    return -ENODEV;

This ensures that only endpoints of the correct type and count are present for the device to work.

Impact

- Found and reported by Syzkaller.
- Fixed as of kernel commit e879386e.

Most serious if you enable panic_on_warn (e.g., secure systems, hardening setups).

- General risk: reliable kernel panic/DoS with a weird USB device.

Should I Worry?

- Are you running a kernel older than March 2024, especially with comedi/vmk80xx and panic_on_warn?

References

- CVE-2024-27001 (NVD)
- The Patch in mainline kernel
- Syzkaller: Fuzzing all the things
- Linux USB Endpoint Overview

Summary

CVE-2024-27001 isn’t the scariest kernel bug, but it shows how a tiny slip in USB endpoint validation can bring down your system—especially for those running with maximum security hardening (panic_on_warn). The fix landed in early 2024, and all distributions should have it soon. As always, keep your kernel current, and beware weird USB gear!


*Feel free to share this post or use it for your own kernel security reviews!*

Timeline

Published on: 05/01/2024 06:15:18 UTC
Last modified on: 05/04/2025 09:01:53 UTC