CVE-2024-35971: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang

Published May 20, 2024
·
Updated

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

8 affected componentsFixes available
debian/linux<=5.10.223-1, <=5.10.234-1
6.1.129-16.1.135-16.12.22-16.12.25-1
Linux Linux kernel>=5.8<6.1.87
Linux Linux kernel>=6.2<6.6.28
Linux Linux kernel>=6.7<6.8.7
Linux Linux kernel=6.9-rc1
Linux Linux kernel=6.9-rc2
Linux Linux kernel=6.9-rc3
Microsoft cbl2 kernel 5.15.186.1-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to 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
  2. 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.
  3. 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

May 20, 2024
CVE Published
via MITRE·09:41 AM
Data Sourced
via MITRE·09:41 AM
DescriptionSeverity
Data Sourced
via NVD·10:15 AM
Description
Data Sourced
via NVD·10:15 AM
RemedySeverityWeaknessAffected Software
Jul 11, 2024
Data Sourced
via Launchpad·07:49 PM
Description
Apr 27, 2025
Data Sourced
via Ubuntu·12:23 AM
RemedyDescriptionSeverityAffected Software
Sep 27, 2025
Data Sourced
via Microsoft·01:02 AM
DescriptionSeverityWeaknessAffected Software
Updated
via Microsoft·08:02 AM
DescriptionSeverity

Frequently Asked Questions

1

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.

2

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.

3

Which software versions are affected by CVE-2024-35971?

CVE-2024-35971 affects Linux kernel versions up to and including 5.10.226-1.

4

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.

5

Can CVE-2024-35971 be exploited remotely?

CVE-2024-35971 does not specifically mention remote exploitation but is related to local network packet handling.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203