CVE-2024-36962

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs<br /> <br /> Currently the driver uses local_bh_disable()/local_bh_enable() in its<br /> IRQ handler to avoid triggering net_rx_action() softirq on exit from<br /> netif_rx(). The net_rx_action() could trigger this driver .start_xmit<br /> callback, which is protected by the same lock as the IRQ handler, so<br /> calling the .start_xmit from netif_rx() from the IRQ handler critical<br /> section protected by the lock could lead to an attempt to claim the<br /> already claimed lock, and a hang.<br /> <br /> The local_bh_disable()/local_bh_enable() approach works only in case<br /> the IRQ handler is protected by a spinlock, but does not work if the<br /> IRQ handler is protected by mutex, i.e. this works for KS8851 with<br /> Parallel bus interface, but not for KS8851 with SPI bus interface.<br /> <br /> Remove the BH manipulation and instead of calling netif_rx() inside<br /> the IRQ handler code protected by the lock, queue all the received<br /> SKBs in the IRQ handler into a queue first, and once the IRQ handler<br /> exits the critical section protected by the lock, dequeue all the<br /> queued SKBs and push them all into netif_rx(). At this point, it is<br /> safe to trigger the net_rx_action() softirq, since the netif_rx()<br /> call is outside of the lock that protects the IRQ handler.