CVE-2024-36962

What it actually does

The vulnerability is a potential deadlock in the ks8851 Ethernet driver for SPI bus interfaces: the IRQ handler protected by a mutex calls netif_rx() which can trigger net_rx_action softirq invoking .start_xmit under the same lock, causing recursive lock acquisition and system hang. The fix queues RX SKBs outside the lock-protected section before calling netif_rx().

Why it matters to the business

Affected Linux systems with ks8851 SPI network hardware may experience kernel-level hangs or unresponsiveness during network activity, causing service outages or requiring reboots. Low EPSS and no KEV listing indicate limited active exploitation risk, but the issue affects kernel stability across many deployments with moderate downstream prevalence.

How an attack unfolds

An attacker sends crafted or high-volume network traffic to trigger RX interrupts on a ks8851 SPI device; with the mutex held in the IRQ handler, netif_rx() schedules softirq processing that attempts to acquire the same lock in start_xmit, resulting in deadlock. No confirmed exploitation by listed threat actors or ransomware campaigns.

How to fix it

Upgrade the Linux kernel to version 6.1.91 or apply commit 8a3ff43dcbab7c96f9e8cf2bd1049ab8d6e59545 from the stable git repository; rebuild, install, and reboot affected systems.

How to confirm the fix worked

Confirm running kernel version is 6.1.91 or newer; inspect ks8851 driver source for the RX queuing changes outside the lock and absence of local_bh_disable/enable calls in the IRQ path.

Typical attack path

1. Send network packets targeting the ks8851 SPI interface to generate RX interrupts
2. Enter IRQ handler and acquire driver mutex
3. Call netif_rx() inside the locked section
4. Trigger net_rx_action softirq that invokes start_xmit
5. Attempt re-acquisition of already-held mutex causing hang

How to detect it

Examine kernel logs and dmesg for deadlock traces, oops, or hung task warnings referencing ks8851, netif_rx, or mutex contention in IRQ context; no widespread exploitation indicators reported.

What your security team should do

• Apply kernel updates to 6.1.91+ on all systems using ks8851 SPI hardware within standard patch windows
• Test updated kernels in non-production environments for driver stability
• Review network logs for unexplained hangs involving ks8851 after deployment