Live › vulnerability › CVE-2026-98619
Go to dashboardOn ops-locked network drivers (fbnic, bnxt), the ethtool offline self test brings the interface down and back up while holding only the instance lock instead of rtnl_lock, so the device is reconfigured without the lock it requires. The sources describe a kernel warning and a race in device reconfiguration; they do not describe a direct way for an attacker to gain code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Hosts that run a Linux kernel with bnxt or fbnic network drivers and use ethtool self tests (for example ) are the ones exposed. Systems without these NICs, or without the ioctl self test in use, are unlikely to be affected; the sources do not say who can trigger the path beyond the local ioctl.
ethtool -tNo product ranges from the sources yet.
uname -r and check whether the kernel predates the fix commit that adds the rtnl opt-in bitlspci | grep -i -E 'bnxt|broadcom|fbnic' to see whether a bnxt or fbnic NIC is presentEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
This page as .md · .json · in your agent: get_signal("CVE-2026-98619")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.