---
id: "CVE-2026-98619"
kind: "vulnerability"
aliases: ["CVE-2026-98619"]
title: "Linux kernel: ethtool self test tears down device without rtnl_lock"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bnxt", "ethtool", "fbnic", "linux-kernel", "package"]
not_affected_if: ["no-bnxt-or-fbnic-nic", "no-ethtool-self-test"]
published_at: "2026-10-18T16:17:14+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:21:18+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98619", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: ethtool self test tears down device without rtnl_lock

On 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, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and check whether the kernel predates the fix commit that adds the rtnl opt-in bit
- Run `lspci | grep -i -E 'bnxt|broadcom|fbnic'` to see whether a bnxt or fbnic NIC is present
- unknown whether the sources give a specific fixed kernel version

## Fix

- Install a Linux kernel build that includes the upstream fix for the ethtool rtnl_lock change (fixed version unknown from sources)
- Avoid running offline ethtool self tests on affected bnxt or fbnic hosts until patched

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98619

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_