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 ks8851irq() thread may call ks8851rxpkts() in case there are any packets in the MAC FIFO, which calls netifrx(). This netifrx() implementation is guarded by localbhdisable() and localbhenable(). The localbhenable() may call dosoftirq() to run softirqs in case any are pending. One of the softirqs is netrxaction, which ultimately reaches the driver .startxmit callback. If that happens, the system hangs. The entire call chain is below:
ks8851startxmitpar from netdevstartxmit netdevstartxmit from devhardstartxmit devhardstartxmit from schdirectxmit schdirectxmit from devqueuexmit devqueuexmit from neighupdate neighupdate from neighupdate neighupdate from arpprocess.constprop.0 arpprocess.constprop.0 from netifreceiveskbonecore netifreceiveskbonecore from processbacklog processbacklog from napipoll.constprop.0 napipoll.constprop.0 from netrxaction netrxaction from dosoftirq dosoftirq from callwithstack callwithstack from dosoftirq dosoftirq from localbhenableip localbhenableip from netifrx netifrx from ks8851irq ks8851irq from irqthreadfn irqthreadfn from irqthread irqthread from kthread kthread from retfromfork
The hang happens because ks8851irq() first locks a spinlock in ks8851par.c ks8851lockpar() spinlockirqsave(&ksp->lock, ...) and with that spinlock locked, calls netifrx(). Once the execution reaches ks8851startxmitpar(), it calls ks8851lockpar() again which attempts to claim the already locked spinlock again, and the hang happens.
Move the dosoftirq() call outside of the spinlock protected section of ks8851irq() by disabling BHs around the entire spinlock protected section of ks8851irq() handler. Place localbhenable() outside of the spinlock protected section, so that it can trigger dosoftirq() without the ks8851par.c ks8851lockpar() spinlock being held, and safely call ks8851startxmitpar() without attempting to lock the already locked spinlock.
Since ks8851irq() is protected by localbhdisable()/localbhenable() now, replace netifrx() with netifrx() which is not duplicating the localbhdisable()/localbhenable() calls.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.22-1Fixed in 6.12.25-1 - Configuration
In ks8851_irq(), disable BHs (local_bh_disable()) around the entire spinlock protected section, then move local_bh_enable() outside that spinlock so it can trigger do_softirq(). This prevents ks8851_start_xmit_par() from calling ks8851_lock_par() while the already-locked spinlock is held (fixes the hang described).
Linux kernel net: ks8851 driver (ks8851_irq handler / ks8851_par.c) local BH (bottom halves) enable/disable placement = Move local_bh_enable() outside the spinlock-protected section of ks8851_irq() and around the entire spinlock protected section disable BHs for the duration of the spinlock; ensure do_softirq() can run without the ks8851_par.c ks8851_lock_par() spinlock held. - Configuration
Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable(), replace calls to netif_rx() with __netif_rx() to avoid duplicating the local BH disable/enable calls.
Linux kernel net: ks8851 driver (ks8851_irq) netif_rx invocation = Replace netif_rx() with __netif_rx()
Event History
Frequently Asked Questions
What is the severity of CVE-2024-35971?
CVE-2024-35971 has a severity rating that indicates it could lead to potential hangs in the system.
How do I fix CVE-2024-35971?
To fix CVE-2024-35971, install the updated Linux kernel packages, specifically versions 6.1.123-1, 6.1.128-1, 6.12.12-1, or 6.12.13-1.
Which software versions are affected by CVE-2024-35971?
CVE-2024-35971 affects Linux kernel versions up to and including 5.10.226-1.
What type of vulnerability is CVE-2024-35971?
CVE-2024-35971 is a vulnerability related to softirqs handling in the Linux kernel's network subsystem.
Can CVE-2024-35971 be exploited remotely?
CVE-2024-35971 does not specifically mention remote exploitation but is related to local network packet handling.