CVE-2026-46031

What it actually does

This is a Linux kernel race/deadlock flaw in the ks8851 Ethernet driver. Under specific interrupt and softirq timing, the driver can re-enter transmit handling while a ks8851 driver lock is already held, causing a kernel deadlock in the network transmit path. The practical impact is availability loss: the affected network interface, kernel thread, or in some systems the whole host can hang or become unstable. Systems using the ks8851 Ethernet controller are the relevant exposure; systems without this driver/device are not meaningfully affected.

Why it matters to the business

Successful exploitation can interrupt network connectivity or cause denial of service on affected Linux systems, which is most relevant for embedded, industrial, appliance, IoT, and real-time Linux deployments that use ks8851 Ethernet hardware. Although this issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, it can still create operational outages where affected devices provide network-facing services or control-plane connectivity.

How an attack unfolds

An attacker needs network reachability to an interface backed by the vulnerable ks8851 driver. By sending traffic that causes receive processing while the device is also transmitting, the attacker can influence the timing of interrupt handling and network softirq processing. In the vulnerable code path, ks8851_irq() holds the driver lock and then packet allocation or bottom-half re-enable behavior can trigger pending transmit softirq processing. That softirq can call ks8851_start_xmit_par(), which attempts to acquire the same lock already held by the IRQ handler. The result is a deadlock, producing kernel stack traces involving ks8851_irq(), net_tx_action(), and ks8851_start_xmit_par(), and causing network or system availability degradation until recovery, watchdog intervention, interface reset, or reboot.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the ks8851 fix for disabling bottom halves around the IRQ handler and related critical sections. Because no exact fixed package versions were provided, use the latest stable kernel from the operating system, appliance, or board vendor and confirm the vendor advisory includes the ks8851 deadlock fix. If immediate patching is not possible, reduce exposure by disabling unused ks8851-backed interfaces, unloading or blacklisting the ks8851 driver where feasible, placing affected devices on trusted or isolated networks, rate-limiting untrusted traffic to affected interfaces, and planning maintenance windows for reboot recovery if the device hangs. CONFIG_PREEMPT_RT systems should be prioritized, but non-RT kernels may also be affected according to the upstream description.

How to confirm the fix worked

Confirm whether the system uses ks8851 hardware or has the ks8851 driver loaded or built into the kernel. Check kernel configuration and modules for ks8851 support, and inspect boot logs for ks8851 device initialization. Validate remediation by confirming the running kernel package version is at or above the vendor-fixed release or contains the upstream patch titled "net: ks8851: Reinstate disabling of BHs around IRQ handler." After updating, reboot into the fixed kernel and verify the active kernel with uname or package-manager tooling. For operational validation, monitor dmesg, journald, and kernel logs during normal network traffic for absence of recurring ks8851 deadlock, soft lockup, hung task, or net_tx_action stack traces.

Typical attack path

1. Identify or reach a Linux system or embedded device using a ks8851 Ethernet interface.
2. Send network traffic to the affected interface, typically enough to exercise receive handling while the device also has outbound transmit activity.
3. Trigger the vulnerable interrupt/softirq timing window in the ks8851 driver.
4. Cause ks8851_start_xmit_par() to attempt to acquire a lock already held by ks8851_irq().
5. Induce a kernel deadlock or networking hang, resulting in denial of service.

How to detect it

There is no known exploit-specific payload or reliable network IOC for this issue. Retrospective detection should focus on kernel and system logs showing ks8851 driver deadlocks, softirq-related stack traces, hung tasks, network watchdog events, interface resets, or unexplained device hangs following inbound network traffic. Review dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, persistent crash logs, pstore/ramoops, netconsole output, and appliance crash bundles. Look for stack traces containing ks8851_irq(), ks8851_start_xmit_par(), net_tx_action(), handle_softirqs(), __local_bh_enable_ip(), or rt_spin_lock(). Correlate these events with spikes in traffic to the affected interface, service unavailability, watchdog reboots, or manual power cycles. Because exploitation results in denial of service rather than code execution, absence of file, process, or account artifacts does not rule out attempted exploitation.

• ks8851_irq
• ks8851_start_xmit_par
• net_tx_action
• handle_softirqs
• __local_bh_enable_ip
• __netdev_alloc_skb
• netdev_alloc_skb_ip_align
• rt_spin_lock
• schedule_rtlock
• rtlock_slowlock_locked
• sch_direct_xmit
• dev_hard_start_xmit
• netdev_start_xmit
• qdisc_run
• __qdisc_run
• irq_thread_fn
• irq_thread
• NETDEV WATCHDOG
• soft lockup
• hung task
• blocked for more than
• ks8851

What your security team should do

• Inventory Linux systems, appliances, and embedded devices that use the ks8851 Ethernet controller or load ks8851-related kernel drivers.
• Prioritize patching internet-reachable, operationally critical, embedded, industrial, appliance, and CONFIG_PREEMPT_RT systems using affected kernels.
• Apply the vendor-provided fixed kernel or a kernel containing the upstream ks8851 bottom-half/IRQ-handler fix, then reboot into the fixed kernel.
• Where patching is delayed, isolate affected interfaces from untrusted networks and consider rate limits or access controls for traffic reaching those interfaces.
• Add monitoring for kernel log signatures associated with ks8851 deadlocks and softirq transmit stack traces.
• Prepare operational recovery procedures for affected devices, including safe interface reset or reboot steps, because exploitation primarily causes denial of service.
• Track vendor advisories for exact fixed versions, since downstream Linux distributions and embedded vendors may backport the fix without changing to a new upstream kernel version.