On modern Linux systems, hardware drivers interact with devices through complex layers of kernel code. Recently, a critical flaw was found in the PowerMac Zilog serial driver (pmac_zilog) code, which could lead to system crashes and denial of service. This vulnerability, now tracked as CVE-2024-26999, was caused by flawed mitigation logic to handle a flood of receive (RX) interrupts. If you're running older PowerMac hardware or emulating it with QEMU, this bug—and the fix—might be relevant to you.

This post explains CVE-2024-26999 in plain language, walks through the buggy code, and shows what was done to fix it. We'll also see how it could be exploited (in theory), and where to read more.

Background: Serial Drivers and RX IRQ Flooding

The pmac_zilog driver manages certain serial ports on PowerMacs. Serial drivers use interrupts to process incoming data ("RX" meaning "receive”). But if too many interrupts arrive too quickly—a condition called "IRQ flood"—the system could become unresponsive or even crash.

Earlier, a mitigation was put in the driver to stop handling RX interrupts if an IRQ flood was detected. However, this fix itself introduced a much worse issue.

When an IRQ flood is detected, the following log message shows up

ttyPZ: pmz: rx irq flood !

But printing this log message (pr_err) in the context of the interrupt handler led to spinlock recursion. Here’s what happened, step-by-step:

`

BUG: spinlock recursion on CPU#, swapper/

`

So, instead of avoiding a deadlock or hang, this "fix" now triggers a definite crash whenever the serial port is used as a console.

The Affected Code

Below is a simplified snippet from the flawed code (from Linux kernel drivers/tty/serial/pmac_zilog.c):

static void pmz_receive_chars(struct uart_port *port)
{
    ...
    if (irq_flood_detected) {
        pr_err("%s: pmz: rx irq flood !\n", port->name);
        // Faulty logic; handling ends here
        return;
    }
    ...
}

And inside pmz_console_write, the same spinlock is taken. So, if a log message is printed while already in a critical section, the kernel triggers a BUG.

The Patch

Since the mitigation was problematic and did not solve the underlying problem (and nobody really hits this case in practice), the Linux kernel maintainers decided to remove this flawed logic entirely. In the patch, the whole "IRQ flood" code was deleted.

Check the patch here

- Commit reference on kernel.org
- LWN.net summary

The patched (fixed) function no longer checks for or logs IRQ floods, avoiding the spinlock recursion bug.

An attacker manages to trigger repeated RX interrupts ("IRQ flood").

When these conditions are met (e.g., via repeated data injection or QEMU emulation glitches), the system will crash with a spinlock recursion BUG, effectively causing Denial of Service (DoS).

Note: On most modern systems, neither the hardware nor the serial console is widely used, making the vulnerability of limited practical impact. Nonetheless, it is a clean example of how well-intentioned mitigations can backfire.

Simple Proof of Concept

For illustrative purposes (and on a test system only), you could try to reproduce the panic if you have QEMU emulating a PowerMac and can cause many RX interrupts. Setting up a script to rapidly write data to the serial port may trigger the bug, but do not do this on production systems.

Official References

- Upstream commit: kernel/git/torvalds/linux.git - Remove flawed mitigation for rx irq flood
- Bug report: QEMU Serial RX flood issue
- Security announcement: *No dedicated CVE page as of posting; follow oss-security for updates.*

If you maintain or use the Linux kernel on PowerMac or QEMU-emulated PowerMac, apply the patch.

- For most users, this bug is harmless—but for systems affected, it could lead to a kernel crash (DoS).

Stay updated by reading kernel changelogs and keeping your systems patched!


*This post is exclusive to this platform. For more Linux kernel analysis, follow our updates! For questions, leave a comment below.*

Timeline

Published on: 05/01/2024 06:15:17 UTC
Last modified on: 03/03/2025 17:47:59 UTC