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 ks8851_irq() AND a TX packet has been sent, then
the driver enables TX queue via netif_wake_queue() which schedules TX
softirq to queue packets for this device.
If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by
the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to
allocate SKBs for the received packets. If netdev_alloc_skb_ip_align()
is called with BH enabled, then local_bh_enable() at the end of
netdev_alloc_skb_ip_align() will trigger the pending softirq processing,
which may ultimately call the .xmit callback ks8851_start_xmit_par().
The ks8851_start_xmit_par() will try to lock struct ks8851_net_par
.lock spinlock, which is already locked by ks8851_irq() from which
ks8851_start_xmit_par() was called. This leads to a deadlock, which
is reported by the kernel, including a trace listed below.
If CONFIG_PREEMPT_RT 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
spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the
deadlock as well.
Fix the problem by disabling BH around critical sections, including the
IRQ handler, thus preventing the net_tx_action() softirq from triggering
during these critical sections. The net_tx_action() 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 schedule_rtlock+0x1c/0x34
schedule_rtlock from rtlock_slowlock_locked+0x548/0x904
rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44
netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188
dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
sch_direct_xmit from __qdisc_run+0x1f8/0x4ec
__qdisc_run from qdisc_run+0x1c/0x28
qdisc_run from net_tx_action+0x1f0/0x268
net_tx_action from handle_softirqs+0x1a4/0x270
handle_softirqs from __local_bh_enable_ip+0xcc/0xe0
__local_bh_enable_ip from __alloc_skb+0xd8/0x128
__alloc_skb from __netdev_alloc_skb+0x3c/0x19c
__netdev_alloc_skb from ks8851_irq+0x388/0x4d4
ks8851_irq from irq_thread_fn+0x24/0x64
irq_thread_fn from irq_thread+0x178/0x28c
irq_thread from kthread+0x12c/0x138
kthread from ret_from_fork+0x14/0x28
Security readout for executives and security teams
Plain-English summary
A Linux network driver for KS8851 Ethernet hardware can deadlock while processing network traffic, potentially freezing networking or the affected system. The documented impact is loss of availability, not data theft or modification. Systems not using this driver and hardware are unlikely to be exposed.
Executive priority
Treat confirmed KS8851 deployments as a high-priority availability issue, especially where a network or system freeze affects operations or safety. Broad emergency action across all Linux systems is unwarranted; first identify active KS8851 use, then apply supported fixed kernels promptly.
Technical view
The ks8851 IRQ path can process a pending transmit softirq while already holding the driver's lock. The transmit callback then attempts to reacquire that lock, causing a deadlock. PREEMPT_RT systems require concurrent receive conditions; non-PREEMPT_RT systems may also trigger the flaw. The fix disables bottom halves around critical sections.
Likely exposure
Exposure requires a Linux kernel with affected ks8851 driver code and compatible KS8851 Ethernet hardware in active use. The supplied version data spans multiple kernel branches and includes ambiguous entries, so assess distribution backports and exact builds rather than relying only on version strings.
Exploitation context
The CVSS 3.1 score is 7.5, with network reachability and high availability impact. However, the bundle marks KEV false and provides no evidence of active exploitation. It does not establish how reliably an unauthenticated remote party can force the necessary driver timing conditions.
Researcher notes
The failure is a lock-recursion deadlock caused by softirq execution inside a driver critical section. The source describes different triggering paths for PREEMPT_RT and standard kernels. Confidentiality and integrity impacts are scored as none. Exact affected-range interpretation remains uncertain because the supplied version records contain duplicated hashes and an ambiguous version labeled "0".
Mitigation direction
Update to a vendor-supported kernel containing the applicable upstream stable fix.
Verify distribution backports because package versions may not match upstream kernel numbering.
If updates must wait, consult the Linux distributor for supported KS8851-specific containment guidance.
Prioritize affected embedded, industrial, or availability-sensitive systems using KS8851 Ethernet hardware.
Validation and detection
Inventory systems for active KS8851 Ethernet hardware and the ks8851 driver.
Check whether CONFIG_PREEMPT_RT is enabled; its absence does not eliminate exposure.
Compare each kernel build with distributor advisories and the referenced stable commits.
Review kernel logs for deadlock traces involving ks8851_irq and ks8851_start_xmit_par.
After updating, confirm networking remains stable under normal transmit and receive workloads.
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-2026-46031 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.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
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.