CVE-2026-98619 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: ethtool: keep rtnl_lock for the ioctl self test
An offline self test that brings the interface down and back up with netif_close() / netif_open() requires rtnl_lock for both. Since the ethtool IOCTL path became rtnl-optional for ops-locked drivers, the ETHTOOL_TEST ioctl runs holding only the netdev instance lock, so on an ops-locked driver the self test now tears the device down without rtnl_lock.
With lockdep this reproduces deterministically on every offline self test on such a driver; note the sole lock held is the instance lock, not rtnl:
WARNING: suspicious RCU usage net/core/netpoll.c:207 suspicious rcu_dereference_protected() usage! 1 lock held by ethtool/107: #0: (&dev->lock){+.+.}, at: dev_ethtool
Call Trace: netpoll_poll_disable __dev_close_many netif_close_many netif_close fbnic_self_test dev_ethtool_locked dev_ethtool dev_ioctl sock_ioctl __x64_sys_ioctl
Without lockdep the same condition trips ASSERT_RTNL() in __dev_close_many() / __dev_open(); that check only samples the global rtnl state, so it can be masked by a concurrent rtnl holder, but the device is still being reconfigured without the lock it requires.
The ethtool self_test is a legacy ioctl-only command, so an ETHTOOL_TEST case is only needed on the ioctl path. Add an opt-in bit for drivers whose self test needs rtnl_lock and set it on the ops-locked drivers whose offline self test tears the interface down and up:
- fbnic (ops-locked via queue_mgmt_ops): fbnic_self_test() offline path uses netif_close() / netif_open(). - bnxt (ops-locked via queue_mgmt_ops): bnxt_self_test() offline path goes through bnxt_close_nic() / bnxt_half_open_nic() / bnxt_half_close_nic() / bnxt_open_nic(), which close and reopen the device.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel network subsystem contains a locking inconsistency within the ethtool self-test ioctl path that affects drivers utilizing ops-locked operations, specifically those managing queues via queue_mgmt_ops such as fbnic and bnxt. The vulnerability arises from a mismatch between the lock requirements for device state transitions and the actual locks held during legacy ioctl execution. Historically, bringing a network interface down using netif_close or opening it with netif_open required holding the rtnl_lock to ensure consistent configuration changes across the networking stack. However, as part of broader efforts to reduce contention on the global rtnl lock for ops-locked drivers, the ethtool ioctl path was modified to operate without this global lock in certain scenarios. This optimization inadvertently created a race condition where offline self-tests that require tearing down and bringing up the interface proceed with only the netdev instance lock held, violating the locking expectations of lower-level network device functions.
This technical flaw manifests deterministically when running an offline self-test on affected drivers. The kernel's internal consistency checks trigger warnings due to suspicious RCU usage within netpoll_poll_disable, which is called during __dev_close_many and subsequently netif_close. Specifically, the code attempts to use rcu_dereference_protected without holding the necessary rtnl_lock, leading to potential data corruption or undefined behavior if concurrent modifications occur. Even in environments where lockdep debugging is disabled, the ASSERT_RTNL checks within __dev_close_many and __dev_open may be masked by a concurrent holder of the rtnl lock from another thread, allowing the device reconfiguration to proceed without proper synchronization. This creates a subtle but serious integrity issue where the network interface state can become inconsistent relative to other kernel subsystems that rely on the assumption that such operations are protected by the global rtnl mutex.
The operational impact of this vulnerability includes potential instability in network connectivity during self-test execution, particularly for drivers like fbnic and bnxt which perform complex queue management operations during device closure and reopening. For fbnic, the offline path explicitly uses netif_close followed by netif_open, while bnxt utilizes a more involved sequence involving bnxt_close_nic, bnxt_half_open_nic, bnxt_half_close_nic, and bnxt_open_nic. In both cases, these sequences assume exclusive access to device configuration resources typically guaranteed by the rtnl_lock. Without this protection, concurrent network management operations could interfere with the self-test process or vice versa, leading to driver crashes, packet loss, or system hangs. The issue is confined to legacy ioctl-based commands and does not affect newer netlink interfaces that handle locking correctly.
To mitigate this vulnerability, developers have implemented an opt-in mechanism for drivers whose self-test routines require rtnl_lock protection during offline operations. By setting a specific flag on ops-locked drivers such as fbnic and bnxt, the kernel ensures that the ethtool ioctl path acquires the necessary global lock before attempting to close or open the network interface. This restores proper synchronization without impacting performance for other drivers that do not require rtnl_lock during self-tests. From a security perspective, this issue aligns with CWE-667 regarding improper locking and CWE-362 concerning concurrent execution issues. It also relates to ATT&CK techniques involving resource manipulation, as the lack of proper locks could potentially be exploited in conjunction with other vulnerabilities to cause denial of service or disrupt network availability. System administrators should ensure their kernels are updated to include this fix to maintain stability during diagnostic operations and prevent potential race conditions that compromise system integrity.