CVE-2026-46031: net: ks8851: Reinstate disabling of BHs around IRQ handler
In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Reinstate disabling of BHs around IRQ handler
If the driver executes ks8851irq() AND a TX packet has been sent, then the driver enables TX queue via netifwakequeue() which schedules TX softirq to queue packets for this device.
If CONFIGPREEMPTRT=y is set AND a packet has also been received by the MAC, then ks8851rxpkts() calls netdevallocskbipalign() to allocate SKBs for the received packets. If netdevallocskbipalign() is called with BH enabled, then localbhenable() at the end of netdevallocskbipalign() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851startxmitpar(). The ks8851startxmitpar() will try to lock struct ks8851netpar .lock spinlock, which is already locked by ks8851irq() from which ks8851startxmitpar() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below.
If CONFIGPREEMPTRT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spinunlockbh(&ks->statelock) in ks8851irq(), which triggers the deadlock as well.
Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the nettxaction() softirq from triggering during these critical sections. The nettxaction() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed.
schedule from schedulertlock+0x1c/0x34 schedulertlock from rtlockslowlocklocked+0x548/0x904 rtlockslowlocklocked from rtspinlock+0x60/0x9c rtspinlock from ks8851startxmitpar+0x74/0x1a8 ks8851startxmitpar from netdevstartxmit+0x20/0x44 netdevstartxmit from devhardstartxmit+0xd0/0x188 devhardstartxmit from schdirectxmit+0xb8/0x25c schdirectxmit from qdiscrun+0x1f8/0x4ec qdiscrun from qdiscrun+0x1c/0x28 qdiscrun from nettxaction+0x1f0/0x268 nettxaction from handlesoftirqs+0x1a4/0x270 handlesoftirqs from localbhenableip+0xcc/0xe0 localbhenableip from allocskb+0xd8/0x128 allocskb from netdevallocskb+0x3c/0x19c netdevallocskb from ks8851irq+0x388/0x4d4 ks8851irq from irqthreadfn+0x24/0x64 irqthreadfn from irqthread+0x178/0x28c irqthread from kthread+0x12c/0x138 kthread from retfromfork+0x14/0x28
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.141.1-1 - Configuration
Modify the ks8851 driver to reinstate disabling of BHs around the IRQ handler critical sections (around ks8851_irq()), so pending net_tx_action softirqs are not triggered while holding the relevant locks; re-enable BHs only after ks8851_irq() finishes processing.
Linux kernel (net: ks8851) Disabling BH (bottom halves) around critical sections including the IRQ handler = Enable/keep BH disabled during ks8851_irq() critical sections and restore BH at the end
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Systems using the Linux ks8851 network driver are affected when the driver’s IRQ handler runs while transmission activity is present. The listed affected software includes the Linux kernel and Microsoft azl3 kernel 6.6.139.1-1.
Does CONFIG_PREEMPT_RT change the triggering conditions?
Yes. With CONFIG_PREEMPT_RT=y, the deadlock requires both a transmitted packet and a packet received by the MAC. Without CONFIG_PREEMPT_RT, the deadlock can also be triggered without a received packet in the RX FIFO.
What symptom indicates that the issue has been triggered?
The driver can deadlock when its transmit callback attempts to acquire a spinlock already held by the IRQ handler. The kernel reports the resulting deadlock, and network processing for the affected device may be disrupted.