CVE-2024-27401

What it actually does

packet_buffer_get in the nosy FireWire driver ignores the caller-supplied user_length when copying packet data, allowing the kernel to write more bytes than the user buffer can hold.

Why it matters to the business

Unpatched Linux systems that expose the nosy device can suffer crashes, memory corruption, or local privilege escalation, forcing unplanned kernel upgrades and potential downtime for servers or workstations using FireWire hardware.

How an attack unfolds

An attacker with read/write access to /dev/nosy opens the device, submits a packet whose length exceeds the user_length value passed to packet_buffer_get, and triggers an out-of-bounds write into the caller's buffer; repeated attempts can corrupt adjacent memory structures to gain elevated privileges.

How to fix it

Upgrade the Linux kernel to commit 67f34f093c0f7bf33f5b4ae64d3d695a3b978285 or later; rebuild and reboot with the patched kernel; if FireWire debugging is unnecessary, blacklist the nosy module.

How to confirm the fix worked

Confirm the running kernel contains commit 67f34f093c0f7bf33f5b4ae64d3d695a3b978285 via 'uname -r' and 'git log' on the kernel tree, or verify that packet_buffer_get now returns zero when user_length is smaller than the head packet.

Typical attack path

1. obtain local access or compromise a process that can open /dev/nosy
2. open the nosy character device
3. craft a packet header with length larger than the subsequent read buffer
4. call the read path that invokes packet_buffer_get without length enforcement
5. trigger kernel-to-user copy that overflows the supplied buffer
6. leverage resulting memory corruption for code execution or denial of service

How to detect it

Search kernel logs and audit trails for unusual opens of /dev/nosy followed by read operations returning partial or zero-length results; correlate with process execution that later exhibits segmentation faults or unexpected privilege changes.

What your security team should do

• Apply the kernel update containing commit 67f34f093c0f7bf33f5b4ae64d3d695a3b978285 within the next maintenance window
• Restrict access to /dev/nosy via udev rules or module blacklisting where FireWire diagnostics are not required
• Monitor EPSS and KEV feeds for any future rise in exploit maturity
• Include the nosy driver in automated kernel patch testing pipelines