Lucene search

K
nvd416baaa9-dc9f-4396-8d5f-8c081fb06d67NVD:CVE-2024-35971
HistoryMay 20, 2024 - 10:15 a.m.

CVE-2024-35971

2024-05-2010:15:11
416baaa9-dc9f-4396-8d5f-8c081fb06d67
web.nvd.nist.gov
linux kernel
vulnerability
resolved
net
irq thread
hang
fix
ks8851
spinlock
softirqs
mac fifo
driver
callback
system
kernel
cve-2024-35971
local_bh_disable
local_bh_enable
do_softirq
ks8851_irq
ks8851_rx_pkts
netif_rx
ks8851_start_xmit_par
netdev_start_xmit
dev_hard_start_xmit
sch_direct_xmit
__dev_queue_xmit
__neigh_update
neigh_update
arp_process
__netif_receive_skb_one_core
process_backlog
__napi_poll
net_rx_action
call_with_stack
__local_bh_enable_ip
irq_thread_fn
kthread
ret_from_fork
ks8851_par.c
ks8851_lock_par
spinlock
spin_lock_irqsave
handler
bhs
section
local_bh_disable()
__netif_rx

6.4 Medium

AI Score

Confidence

Low

0.0004 Low

EPSS

Percentile

10.4%

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.

6.4 Medium

AI Score

Confidence

Low

0.0004 Low

EPSS

Percentile

10.4%