cve/2024/CVE-2024-26999.md

### [CVE-2024-26999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-26999)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=2.6.12%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:serial/pmac_zilog: Remove flawed mitigation for rx irq floodThe mitigation was intended to stop the irq completely. That may bebetter than a hard lock-up but it turns out that you get a crash anywayif you're using pmac_zilog as a serial console:ttyPZ0: pmz: rx irq flood !BUG: spinlock recursion on CPU#0, swapper/0That's because the pr_err() call in pmz_receive_chars() results inpmz_console_write() attempting to lock a spinlock already locked inpmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatalBUG splat. The spinlock in question is the one in struct uart_port.Even when it's not fatal, the serial port rx function ceases to work.Also, the iteration limit doesn't play nicely with QEMU, as can beseen in the bug report linked below.A web search for other reports of the error message "pmz: rx irq flood"didn't produce anything. So I don't think this code is needed any more.Remove it.

### POC

#### Reference
- https://git.kernel.org/stable/c/69a02273e288011b521ee7c1f3ab2c23fda633ce

#### Github
No PoCs found on GitHub currently.