In the Linux kernel, the following vulnerability has been resolved: net: ethtool: keep rtnl_lock for the ioctl self test An offline self t

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.