CVE-2024-35971 in Linux
Summary
by MITRE • 05/20/2024
In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below:
ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork
The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens.
Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock.
Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2025
The vulnerability described in CVE-2024-35971 affects the Linux kernel's ks8851 network driver implementation, specifically within the interrupt handling mechanism. This issue represents a classic deadlock scenario that arises from improper handling of soft interrupts within a spinlock-protected context. The ks8851 driver is responsible for managing the Kingstech ks8851 ethernet controller, which is commonly found in embedded systems and industrial networking equipment. The flaw manifests when the driver's interrupt thread processes incoming packets and subsequently attempts to schedule soft interrupts, creating a circular dependency that results in system hangs.
The technical root cause stems from the improper ordering of interrupt handling operations within the ks8851_irq() function. When packets are present in the MAC FIFO, the driver calls ks8851_rx_pkts() which invokes netif_rx() to deliver packets to the network stack. This netif_rx() implementation uses local_bh_disable() and local_bh_enable() to manage bottom-half execution. However, when local_bh_enable() executes, it may trigger do_softirq() which can invoke net_rx_action, ultimately leading back to the driver's start_xmit callback. This creates a recursive execution path that ends in a deadlock when the same spinlock is attempted to be acquired twice. The call chain demonstrates how the system can become trapped in a loop where ks8851_irq() holds a spinlock, calls netif_rx(), which leads to softirq processing, which in turn calls back into the same driver with the spinlock already held.
The operational impact of this vulnerability is severe as it can cause complete system hangs or lockups, particularly in embedded systems where the ks8851 driver is commonly deployed. This affects systems that rely on continuous network connectivity for industrial control, IoT devices, or embedded networking applications. The hang occurs because the driver's interrupt handler holds a spinlock throughout the entire packet processing sequence, preventing any other execution context from accessing the same lock, including the softirq handler that needs to execute the driver's transmit function. This vulnerability affects the broader network subsystem and can potentially impact network availability for all interfaces managed by the ks8851 driver, making it a critical issue for embedded and industrial network deployments.
The mitigation strategy implemented in the kernel fix involves reorganizing the interrupt handling sequence to properly separate spinlock protection from soft interrupt processing. By disabling BHs around the entire spinlock-protected section of the interrupt handler and moving the local_bh_enable() call outside of the spinlock context, the fix prevents the recursive locking scenario. This approach follows established kernel development practices for handling soft interrupts within interrupt contexts, aligning with the principle that spinlocks should be held for minimal time to prevent deadlock conditions. The solution also replaces netif_rx() with __netif_rx() to avoid duplicate local_bh_disable/enable operations, which is consistent with kernel coding standards and reduces the complexity of interrupt handling. This fix addresses the core issue identified in CWE-121, which deals with stack-based buffer overflow conditions that can lead to system instability, and aligns with ATT&CK technique T1499.001 for network denial of service through system resource exhaustion. The resolution ensures proper interrupt handling semantics and prevents the specific deadlock condition that would otherwise cause system hangs in network-intensive scenarios involving the ks8851 driver.