CVE-2024-35971: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
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.
Security readout for executives and security teams
Plain-English summary
A flaw in Linux systems using the KS8851 network driver can cause the entire system to hang while processing network traffic. It affects availability rather than data confidentiality or integrity. Devices using this specific hardware and driver deserve prompt assessment; Linux systems without it are unlikely to be exposed.
Executive priority
Prioritize assessment promptly where KS8851-based devices support critical, remote, or difficult-to-recover services. Patch on the normal urgent cycle after confirming exposure. Broad emergency action across all Linux systems is not justified because the vulnerable driver and hardware path must be present.
Technical view
The KS8851 IRQ thread can invoke receive processing while holding the driver's spinlock. Pending network softirqs may re-enter the transmit callback, which attempts to acquire the same lock and deadlocks. The published fix prevents softirq execution inside the protected section by extending bottom-half suppression and using __netif_rx().
Likely exposure
Exposure is limited to Linux systems using the KS8851 parallel-interface network driver and affected kernel code. The bundle lists affected kernel versions but does not provide reliable distribution-specific package mappings. Embedded, industrial, or appliance deployments using this network controller may warrant particular attention.
Exploitation context
The CVSS assessment describes network-reachable, low-complexity, unauthenticated availability impact. However, the supplied sources do not report public exploitation, and the CVE is not identified as CISA KEV. Treat remote denial of service as plausible from the technical conditions, not confirmed exploitation.
Researcher notes
The failure is recursive acquisition of the ks8851_par spinlock: receive handling under the IRQ-thread lock can execute net_rx_action and reach ks8851_start_xmit_par, which requests that lock again. The fix moves possible softirq execution beyond the locked region. The bundle provides four stable-tree commits but insufficient metadata to map every distribution kernel precisely.
Mitigation direction
Identify systems using the KS8851 parallel-interface network driver.
Apply a vendor kernel update containing the applicable published fix or backport.
Prioritize exposed appliances where a system hang would disrupt critical operations.
Consult the Linux or distribution vendor for exact fixed package versions.
Validation and detection
Confirm whether the KS8851 driver is configured, loaded, and attached to network hardware.
Record running kernel and distribution package versions on potentially affected systems.
Verify the vendor update includes an applicable referenced kernel fix.
Run vendor-approved network regression tests and confirm systems remain responsive.
Monitor affected devices for unexplained hangs associated with network activity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35971 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.