CVE-2024-27401 - Linux Kernel FireWire `nosy` Buffer Overflow Vulnerability Explained

In early 2024, a new Linux kernel vulnerability was patched involving the FireWire subsystem, specifically within the nosy module — a tool used for FireWire traffic sniffing and debugging. Identified as CVE-2024-27401, this flaw could lead to a buffer overflow in user space under certain conditions, enabling escalation of privileges or causing crashes if exploited.

In this article, we’ll break down what happened, what’s vulnerable, how it got fixed, and precautions you should take. We’ll also show snippets of the old and new code, so you can see the difference yourself.

The Issue: Buffer Overflows In nosy

The FireWire nosy driver is used for passive monitoring of IEEE 1394 (FireWire) traffic. Prior to the patch, when a user-space application requested packets from the nosy device, the kernel would not sufficiently check that the user's buffer (user_length) was large enough to handle the requested packet. If the head packet in the buffer was bigger than the user-supplied memory, it could write past the end of that space — a classic user-space buffer overflow.

Potential impact

- Could be used by malicious applications with access to /dev/nosy to escalate privileges.

The Patch: Respecting User Buffer Size

The main problem was that the function packet_buffer_get didn’t properly ensure the kernel wouldn’t copy more data than the user’s provided buffer could hold. The fix now makes sure to:
- Return if the packet’s length is larger than the buffer provided by the user, clearly signaling to the caller that more space is needed.

Code Before the Fix (Vulnerable)

int packet_buffer_get(struct packet_buffer *pb, void __user *buffer, size_t user_length)
{
    // ...other code...
    // Potentially dangerous copy:
    copy_to_user(buffer, pb->data, pb->head->length);
    // ...other code...
}

Here, notice there’s no check that pb->head->length is less than or equal to user_length. If an attacker supplies a small buffer, but the kernel tries to copy a big packet into it, user-land memory after the buffer will get overwritten.

Code After the Fix (Patched)

int packet_buffer_get(struct packet_buffer *pb, void __user *buffer, size_t user_length)
{
    size_t packet_length = pb->head->length;

    // Check for size mismatch
    if (packet_length > user_length)
        return ;   // Tell user to try with a larger buffer

    if (copy_to_user(buffer, pb->data, packet_length))
        return -EFAULT;

    // ...rest of the code...
}

Now, the function first checks if the packet fits in the provided user buffer. If it doesn’t, no data is copied, and is returned.

Suppose a user-space program does this (pseudocode)

int fd = open("/dev/nosy", O_RDONLY);
char buffer[8];
int bytes = read(fd, buffer, sizeof(buffer)); // Kernel tries to copy 1024 bytes!

If there’s a large pending packet, the kernel would accidentally copy way more than 8 bytes into your 8-byte buffer, causing corruption of adjacent memory.

Upstream Patch:

- Git commit diff (kernel.org)

CVE Record:

- NVD CVE-2024-27401 Record

LKML Discussion:

- LKML Patch Posting

You’re affected if

- You run a Linux kernel with FireWire support (CONFIG_FIREWIRE), and particularly if you use the nosy driver (which is not typically enabled by default).
- You allow user-space access to /dev/nosy by untrusted users.

How to fix

- Upgrade to a kernel that includes this patch (mainline 6.8+ and backports to stable trees for supported versions).
- Restrict access to /dev/nosy to trusted users only.

Key Takeaways

- CVE-2024-27401 is a user-space buffer overflow in the nosy FireWire debugging driver for Linux, caused by not checking that user buffers are big enough.

Fixed by rejecting reads that would overflow user memory, making the kernel safer.

- Unless you use FireWire debugging in production, this won’t affect typical desktop or server setups.

Timeline

Published on: 05/14/2024 15:12:29 UTC
Last modified on: 05/04/2025 09:04:18 UTC