Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-46287

CVE-2026-46287: Linux Kernel txgbe RTNL Lock Vulnerability

CVE-2026-46287 is an RTNL lock assertion flaw in the Linux kernel txgbe network driver that triggers warnings during module removal. This article covers the technical details, affected systems, and mitigation steps.

Published:

CVE-2026-46287 Overview

CVE-2026-46287 is a Linux kernel vulnerability in the txgbe network driver. The flaw triggers an RTNL (Routing Netlink) assertion warning when the module is removed on systems using copper NICs with an external PHY. The driver calls phylink_connect_phy() during probe and phylink_disconnect_phy() during remove, but the latter requires the RTNL lock to be held. Without proper locking, removing the module emits a WARNING in drivers/net/phy/phylink.c at line 2351. The upstream fix wraps the phylink_disconnect_phy() call with rtnl_lock() and rtnl_unlock().

Critical Impact

Removing the txgbe kernel module on affected systems produces an RTNL assertion warning, indicating a locking contract violation in the network subsystem.

Affected Products

  • Linux kernel txgbe driver (Wangxun 10Gb Ethernet)
  • Systems using copper NICs with external PHY managed by phylink
  • Stable kernel branches prior to commits referenced in the fix series

Discovery Timeline

  • 2026-06-08 - CVE-2026-46287 published to NVD
  • 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46287

Vulnerability Analysis

The txgbe driver manages Wangxun 10Gb Ethernet adapters in the Linux kernel. For copper NICs paired with an external PHY, the driver attaches a phylink instance during probe using phylink_connect_phy(). On module unload, the driver detaches the PHY via phylink_disconnect_phy().

The phylink subsystem requires callers of phylink_disconnect_phy() to hold the RTNL lock. The txgbe remove path did not acquire this lock before invoking the disconnect routine. As a result, an ASSERT_RTNL() check in drivers/net/phy/phylink.c at line 2351 fires when rmmod txgbe is executed.

The call chain from the captured warning shows txgbe_remove_phy() invoking phylink_disconnect_phy() from txgbe_remove(), reached via pci_device_remove() and driver_unregister() from the __do_sys_delete_module syscall path. The warning does not corrupt state but signals that an internal locking contract has been violated, which may mask race conditions during teardown.

Root Cause

The root cause is a missing RTNL lock acquisition in the driver's remove handler. phylink_disconnect_phy() modifies network device state and must be serialized against other network configuration paths. The txgbe remove function called this routine without first invoking rtnl_lock(), violating the documented locking requirement.

Attack Vector

Triggering the warning requires local privileges to load and unload kernel modules, typically CAP_SYS_MODULE. The condition is reachable only on hardware with a copper NIC and external PHY served by txgbe. There is no remote attack vector and no evidence of exploitation. The issue is a code-correctness defect rather than a directly exploitable memory safety bug.

The fix adds rtnl_lock() before and rtnl_unlock() after the phylink_disconnect_phy() call in the txgbe_remove_phy() function. See the upstream patches referenced in the Kernel Git Commit 0305e71 and the Kernel Git Commit e159f05 for technical details.

Detection Methods for CVE-2026-46287

Indicators of Compromise

  • Kernel log entry: RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
  • WARNING stack trace referencing phylink_disconnect_phy+0xd8/0xf0 [phylink]
  • Stack frames including txgbe_remove_phy and txgbe_remove during module unload

Detection Strategies

  • Parse dmesg and /var/log/kern.log for RTNL: assertion failed strings tied to the phylink module.
  • Inventory hosts running the txgbe driver against pre-patch kernel versions using modinfo txgbe and uname -r.
  • Audit kernel build versions across the fleet to confirm inclusion of the fix commits listed in the kernel.org references.

Monitoring Recommendations

  • Forward kernel ring buffer entries to a centralized log pipeline and alert on WARNING events originating from network drivers.
  • Track rmmod and modprobe -r execution on hosts with Wangxun NICs to correlate operational activity with warning events.
  • Include kernel taint flag changes in host posture telemetry to surface systems impacted by driver warnings.

How to Mitigate CVE-2026-46287

Immediate Actions Required

  • Apply the stable kernel update that contains the upstream txgbe RTNL locking fix.
  • Avoid unloading the txgbe driver on unpatched systems if the warning is undesirable during maintenance.
  • Identify hosts using copper Wangxun NICs with external PHY since they are the only affected configuration.

Patch Information

The vulnerability is resolved by upstream commits that wrap phylink_disconnect_phy() with rtnl_lock() and rtnl_unlock() in the txgbe remove path. The fix is available in the kernel stable tree via the Kernel Git Commit 0305e71, Kernel Git Commit 3e223a7, Kernel Git Commit 6c5ec52, Kernel Git Commit d29cafc, and Kernel Git Commit e159f05. Apply the vendor kernel update aligned with your distribution.

Workarounds

  • Keep the txgbe module loaded during normal operations to avoid invoking the affected remove path.
  • Schedule kernel updates that incorporate the fix instead of relying on driver reloads for troubleshooting.
  • Use distribution-provided backports for long-term support kernels where direct upgrades are not feasible.
bash
# Verify whether the txgbe driver is loaded and on affected hardware
lsmod | grep txgbe
ethtool -i <interface> | grep -E 'driver|version'
dmesg | grep -i 'RTNL: assertion failed'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.