CVE-2026-46287: Linux txgbe Driver RTNL Locking Defect

Technical summary

CVE-2026-46287 is a kernel synchronization bug in the txgbe driver's module removal path. The driver calls phylink_disconnect_phy() in its remove function without holding the RTNL mutex, violating phylink's locking contract documented at phylink.c line 2351. The assertion warning occurs because phylink_disconnect_phy() expects callers to hold rtnl_lock(). The copper NIC variant with external PHY is affected; integrated PHYs do not trigger this code path during probe/remove. Kernel versions 7.0-rc4 and likely earlier show evidence of the bug in kernel logs. The remediation requires adding rtnl_lock() and rtnl_unlock() calls around the phylink_disconnect_phy() invocation in the txgbe_remove_phy() function.

Business impact

This vulnerability primarily affects system stability and operational visibility rather than security posture. Administrators unloading the txgbe module will encounter repeated kernel warnings, potentially filling system logs and complicating troubleshooting. The warning does not cause data loss or kernel panic under normal circumstances, but repeated warnings can mask other important kernel messages and create noise in monitoring systems. Organizations managing large fleets of systems with Micro-Star X670E motherboards or other hardware using txgbe controllers may experience increased support burden. The medium CVSS score (5.5) reflects the local-only requirement and absence of confidentiality or integrity impact.

Affected systems

The Linux kernel is affected. The txgbe driver code path is triggered on systems with Micro-Star X670E GAMING PLUS WIFI motherboards and equivalent hardware using copper-based NIC with external PHY configuration. Kernel versions at or near 7.0-rc4 (and likely earlier releases) contain the vulnerable code. Systems using txgbe controllers with integrated PHYs, or users who do not unload the driver module, do not encounter this issue. The vulnerability is not present in driver-only patches but requires kernel code remediation.

Exploitability

Exploitability is minimal. The vulnerability requires local access and the ability to execute module unload operations (typically requiring root or CAP_SYS_MODULE capability). An unprivileged user cannot trigger the assertion. The bug manifests as a kernel warning rather than a crash or privilege escalation vector. An attacker with local administrative access could deliberately trigger the warning to fill system logs (denial-of-service against log infrastructure), but this is not a practical attack vector compared to other kernel DoS methods. No user-space exploit or weaponized proof-of-concept is known.

Remediation

The Linux kernel project has resolved this by adding proper RTNL locking in the txgbe driver's remove path. Administrators should apply kernel updates that include the phylink and txgbe synchronization fixes, particularly patches addressing the RTNL assertion in phylink_disconnect_phy(). Verify against official kernel.org security advisories and your Linux distribution's kernel release notes for the exact patch version. Interim mitigation consists of avoiding repeated module unload/reload cycles on affected hardware, though this provides no security benefit.

Patch guidance

Check your distribution's kernel security advisories and release notes for patches merged after the CVE publication date (2026-06-08). The fix involves commits to the txgbe driver and phylink subsystem adding rtnl_lock()/rtnl_unlock() around the disconnect call. Verify the specific kernel version against your vendor's advisory—Ubuntu, RHEL, Debian, and other distributions backport fixes at different release cadences. Automated patch management systems should prioritize kernel updates flagged for this CVE, though the medium severity should not override critical or high-severity patches in deployment order.

Detection guidance

Monitor kernel logs (dmesg, journalctl) for the specific warning: 'RTNL: assertion failed at drivers/net/phy/phylink.c (2351)' or 'phylink_disconnect_phy' warnings. Check system logs during module operations or driver reload cycles. Automated log analysis can alert on this pattern. This is not a runtime exploitation indicator but rather a module lifecycle event, so log-based detection is primarily useful for confirming exposure and validating patches post-deployment. Network behavior is unaffected; IDS/IPS systems will not detect this vulnerability.

Why prioritize this

Despite the medium CVSS score, this vulnerability warrants prompt but not emergency remediation. The local-only requirement and lack of confidentiality/integrity impact mean it poses no direct security risk. However, operational impact is real: system administrators deploying updates on affected hardware will encounter disruptive kernel warnings. Remediation should be scheduled within normal kernel update cycles (1–3 months), grouped with other kernel patches. Organizations heavily dependent on systems using Micro-Star X670E or equivalent txgbe hardware should prioritize slightly higher within their patch windows. Low-impact systems can defer until the next regular kernel update period.

Risk score, explained

The CVSS 3.1 score of 5.5 (Medium) is derived from: AV:L (local attack vector, module unload requires local access), AC:L (low attack complexity, unload is straightforward), PR:L (low privilege required, CAP_SYS_MODULE or root), UI:N (no user interaction needed), S:U (scope unchanged), C:N (no confidentiality impact), I:N (no integrity impact), A:H (high availability impact due to kernel warning storm potential). The score correctly captures that this is not a security vulnerability in the threat model sense but a reliability/operational defect. Organizations focused on robust audit logs and minimal noise should weight the availability component more heavily than the numerical score alone suggests.

Frequently asked questions