CVE-2026-46287

What it actually does

This is a Linux kernel driver locking defect in the txgbe network driver. On systems using a txgbe-supported copper NIC with an external PHY, the driver disconnects the PHY during module removal without holding the RTNL lock, causing a kernel RTNL assertion warning in phylink_disconnect_phy(). The observable effect is a kernel warning and stack trace during driver unload or device removal; exploitation requires the ability to remove the kernel module or otherwise trigger the driver removal path, which typically requires root or CAP_SYS_MODULE privileges. Based on the available description, this is primarily a local reliability and correctness issue rather than a remotely exploitable vulnerability.

Why it matters to the business

Organizations running affected Linux kernels on hardware using the txgbe driver may experience kernel warnings, noisy monitoring alerts, and potential disruption during network driver unload, maintenance, device removal, or kernel/module lifecycle operations. The operational risk is highest for systems where txgbe-backed network interfaces are important for availability, but the overall exploitation urgency is low because it is not in CISA KEV, is not associated with ransomware use, has very low EPSS, and no exploit maturity is reported.

How an attack unfolds

An attacker would first need local administrative capability sufficient to unload kernel modules or detach the txgbe PCI driver. On a host with a txgbe copper NIC using an external PHY, the attacker triggers the removal path, for example by unloading the txgbe module. During removal, the vulnerable driver calls phylink_disconnect_phy() without the required RTNL lock, causing the kernel to emit an RTNL assertion warning and stack trace. There is no evidence from the provided data that this enables remote code execution, privilege escalation, or unauthenticated compromise; the practical attacker value is limited to causing local kernel warning conditions or disrupting maintenance workflows if module removal is part of operations.

How to fix it

Apply a Linux kernel update that includes the txgbe driver fix adding rtnl_lock() and rtnl_unlock() around phylink_disconnect_phy() in the driver remove path. If no vendor-specific fixed version is listed, obtain the fix through the appropriate distribution kernel advisory, long-term stable kernel update, or vendor-supported kernel package. As interim mitigation, avoid unnecessary unloading or reloading of the txgbe module on affected systems, restrict module unload capabilities to trusted administrators, and schedule network driver maintenance during controlled windows. Where practical, prevent untrusted administrative workflows from invoking rmmod, modprobe -r, or PCI driver unbind operations against txgbe-backed interfaces.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for the txgbe remove-path RTNL locking issue. Validate exposure by checking whether the txgbe module is loaded or the system has txgbe-supported NICs. On patched non-production systems, controlled removal of the txgbe module should no longer produce an RTNL assertion warning from phylink_disconnect_phy(). Review kernel logs after driver removal or maintenance for absence of the relevant warning and stack trace. Use vendor package metadata, changelogs, or kernel source inspection to verify that phylink_disconnect_phy() in the txgbe removal path is protected by rtnl_lock() and rtnl_unlock().

Typical attack path

1. Obtain local privileged access to a Linux system, typically root or equivalent capability to unload kernel modules.
2. Confirm the system uses hardware supported by the txgbe driver, especially a copper NIC with an external PHY.
3. Trigger the txgbe driver removal path, such as by unloading the txgbe kernel module or detaching the relevant PCI driver.
4. Cause phylink_disconnect_phy() to execute without the RTNL lock during removal.
5. Observe kernel RTNL assertion warnings and stack traces in kernel logs.

How to detect it

To determine whether this condition has already occurred, review kernel logs and system journals for RTNL assertion warnings, phylink_disconnect_phy stack traces, and txgbe driver removal events. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, audit logs for module unload activity, and EDR telemetry for privileged execution of rmmod or modprobe -r. Focus on events where rmmod, delete_module, txgbe_driver_exit, txgbe_remove, txgbe_remove_phy, pci_device_remove, or phylink_disconnect_phy appear close together in time. Also review administrative activity around network maintenance windows, PCI driver unbind actions, and kernel module lifecycle events. Because this issue manifests as a kernel warning rather than a known post-exploitation implant or payload, indicators are mainly operational artifacts rather than attacker-specific IOCs.

• RTNL: assertion failed at drivers/net/phy/phylink.c
• WARNING: drivers/net/phy/phylink.c:2351
• phylink_disconnect_phy
• txgbe_remove_phy
• txgbe_remove
• txgbe_driver_exit
• __do_sys_delete_module
• __x64_sys_delete_module
• Comm: rmmod
• rmmod txgbe
• modprobe -r txgbe
• pci_unregister_driver
• bus_remove_driver
• driver_unregister
• /sys/bus/pci/drivers/txgbe/unbind

What your security team should do

• Prioritize patching Linux systems that use txgbe-supported NICs in production or availability-sensitive network paths.
• Confirm whether the txgbe module is loaded across Linux fleets using kernel module inventory or endpoint telemetry.
• Restrict kernel module unload operations to trusted administrators and monitor use of rmmod, modprobe -r, and PCI driver unbind actions.
• Review kernel logs for prior RTNL assertion warnings involving phylink_disconnect_phy and txgbe_remove to identify systems that have already hit the vulnerable path.
• Treat this as a low-likelihood exploitation issue unless other local privilege or operational abuse paths are present, but include the fix in regular kernel patch cycles.
• If affected systems are network-critical, test the vendor kernel update in staging before rollout to avoid unintended NIC driver regressions.