In early 2024, a subtle but significant vulnerability was identified in the Linux kernel USB serial driver for the mos784 chip. Tracked as CVE-2024-42244, this bug could lead to system crashes (kernel panics) when resuming from sleep, particularly for users with adapters like the Delock 87414 (USB 2. to 4x serial). Let’s break down the issue, see what it means, look at the code, discuss the possible impact, and explore the fix—all in straightforward language.

What is CVE-2024-42244?

The MOSCHIP mos784 USB-to-serial driver had a crash bug introduced by earlier kernel changes. When a system woke up from suspend (sleep) mode, the kernel would try to resume the USB serial ports—triggering a crash because the resume code mishandled context pointers for multiple read URBs (USB Request Blocks).

This vulnerability affects the kernel’s ability to correctly manage multiple active USB serial ports via the mos784 chip after suspend/resume cycles.

Why Did This Happen?

Back in 2011, the mos784 driver was patched to support multiple read URBs for each serial port (for higher performance and robustness). In 2016, the Linux kernel core started using a generic resume method for USB serial drivers that lacked their own custom functions (see Commit c49cfa917025).

Unfortunately, the generic resume code didn’t account for the specific requirements (i.e., correct context pointers) needed by the mos784’s two simultaneous read URBs. As a direct result, after resuming, one of those URBs had an invalid context pointer, leading to a _use after free_ or _null pointer dereference_ when accessed—causing a nasty crash.

How Can It Be Exploited?

Any local or remote process that can trigger device suspend/resume actions with an affected USB serial device connected (e.g., via power management tweaks or simply by closing the laptop lid) could cause the kernel to crash—leading to a denial of service.

No code execution or privilege escalation is known for this bug, but it is a serious stability issue.

Here’s how you might trigger this bug on a vulnerable kernel

# Connect a Delock 87414 or similar device using mos784 chip
sudo dmesg | grep mos784

# Open 2 serial ports to ensure both read URBs are used
minicom -D /dev/ttyUSB &
minicom -D /dev/ttyUSB1 &

# Put the machine to sleep (suspend-to-RAM)
sudo systemctl suspend

# Wake up the system
# At this point, the kernel may panic and reboot upon access to the serial device

Note: The exploit is mostly _accidental_—users simply resuming their laptops with these adapters attached risk a kernel panic.

Under the Hood: The Buggy Code

The crash stemmed from a missing, dedicated resume() method in the mos784 driver. The kernel’s USB serial core fallback code did not properly set context pointers for the second read URB.

Excerpt from buggy logic (simplified for clarity)

// On resume, both URBs are resubmitted
usb_fill_bulk_urb(read_urb1, dev, ...);
read_urb1->context = port;  // Correct

usb_fill_bulk_urb(read_urb2, dev, ...);
// context left as usb_serial_port vs mos784_port

So, when the second URB completes, the driver dereferences the wrong context, leading to a crash.


## The Patch: Dedicated Suspend/Resume Functions

To fix CVE-2024-42244, the Linux kernel team introduced custom suspend/resume handlers to the mos784 driver. These ensure both read URBs are set up with proper context.

Key ideas of the fix

- Implement driver-specific suspend()/resume() methods.

Resubmit both read URBs on resume, each with the right context (mos784_port structure).

- Properly set any relevant port flags, kill pending URBs safely, and avoid touching already disconnected/closed ports.

Patch Snippet (Simplified)

static int mos784_resume(struct usb_serial *serial)
{
    struct moschip_port *port;
    int i;

    for (i = ; i < serial->num_ports; ++i) {
        port = usb_get_serial_data(serial->port[i]);
        if (!port)
            continue; // Port not open

        // Safe re-init and submit of both read URBs
        setup_urb(port->read_urb1, ...);
        port->read_urb1->context = port;

        setup_urb(port->read_urb2, ...);
        port->read_urb2->context = port;

        usb_submit_urb(port->read_urb1, GFP_KERNEL);
        usb_submit_urb(port->read_urb2, GFP_KERNEL);
    }
    return ;
}

Actual patch and details:
- Linux Kernel Commit Fix

Who Is Affected?

- Users running modern Linux kernel versions (4.x → 6.x pre-patch) with mos784-compatible USB-to-serial adapters (Delock, others).
- Embedded systems, legacy hardware, any device using these adapters under suspend/resume cycles.

How To Fix It

Upgrade your kernel to a version including the fix (June 2024 and later mainline and stable series).

Or, if you maintain your own kernel tree, backport the patch from the references above.

References

- CVE Description: CVE-2024-42244 at cve.org _(pending syndication, expected mid-2024)_

Fix Commit:

USB: serial: mos784: fix crash on resume (git.kernel.org)

USB Serial Core Change:

Commit c49cfa917025

Summary

CVE-2024-42244 is a practical example of how complex kernel code can have real-world impacts, especially for specialized hardware adapters after core framework changes. While not a code execution bug, it’s critical for environments where system stability and uptime are essential.

If you use mos784-based adapters—and rely on suspend/resume—patch your kernel now!


> _Exclusive write-up by LinuxSecurityNinja - June 2024_

Timeline

Published on: 08/07/2024 16:15:47 UTC
Last modified on: 08/08/2024 14:53:27 UTC