On 3/11/26 4:11 PM, Jianzhou Zhao wrote:

Subject: [BUG] net: kernel NULL pointer dereference in __ethtool_get_link_ksettings

Dear Maintainers,

We are writing to report a NULL pointer dereference vulnerability within the `__ethtool_get_link_ksettings()` function. This bug was found by our custom fuzzing tool, RacePilot. The bug occurs when an internal subsystem (e.g., `smc` routing or `infiniband` querying a hardware port) attempts to retrieve the link speed of an `ipvlan` interface that is layered on top of a virtual or device hierarchy lacking `ethtool_ops`. We observed this bug on the Linux kernel version 6.18.0-08691-g2061f18ad76e-dirty.

Call Trace & Context
==================================================================
BUG: kernel NULL pointer dereference, address: 00000000000001f8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 8322 Comm: kworker/0:9 Not tainted 6.18.0-08691-g2061f18ad76e-dirty #50 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events smc_ib_port_event_work
RIP: 0010:__ethtool_get_link_ksettings+0x5c/0x140 net/ethtool/ioctl.c:443
...
Call Trace:
  <TASK>
  ipvlan_ethtool_get_link_ksettings+0x2c/0x40 drivers/net/ipvlan/ipvlan_main.c:411
  __ethtool_get_link_ksettings+0x107/0x140 net/ethtool/ioctl.c:450
  ib_get_eth_speed+0xd2/0x6d0 drivers/infiniband/core/verbs.c:1999
  rxe_query_port+0x14a/0x270 drivers/infiniband/sw/rxe/rxe_verbs.c:62
  __ib_query_port drivers/infiniband/core/device.c:2148 [inline]
  ib_query_port drivers/infiniband/core/device.c:2180 [inline]
  ib_query_port+0x310/0x440 drivers/infiniband/core/device.c:2170
  smc_ib_remember_port_attr net/smc/smc_ib.c:364 [inline]
  smc_ib_port_event_work+0xfa/0x690 net/smc/smc_ib.c:388
...
==================================================================

Execution Flow & Code Context
When backend kernel systems like infiniband (`ib_get_eth_speed`) call `__ethtool_get_link_ksettings()` on a top-level `ipvlan` device to evaluate underlying ethernet capabilities, the execution delegates successfully through the device's mapped proxy routine. However, `ipvlan` triggers a nested fallback lookup to the physical baseline carrier without validating whether the carrier inherently supports ethtool operations:

// drivers/net/ipvlan/ipvlan_main.c
static int ipvlan_ethtool_get_link_ksettings(struct net_device *dev,
					     struct ethtool_link_ksettings *cmd)
{
	const struct ipvl_dev *ipvlan = netdev_priv(dev);

	return __ethtool_get_link_ksettings(ipvlan->phy_dev, cmd); // <-- Nested fallback call onto phy_dev
}

Unfortunately, the exported helper routine `__ethtool_get_link_ksettings()` relies strictly on `dev->ethtool_ops` being a valid populated pointer and makes no assertions defensively prior to calling the callback layout:

// net/ethtool/ioctl.c
int __ethtool_get_link_ksettings(struct net_device *dev,
				 struct ethtool_link_ksettings *link_ksettings)
{
	ASSERT_RTNL();

	if (!dev->ethtool_ops->get_link_ksettings) // <-- NULL pointer dereference (fault at +0x1f8)
		return -EOPNOTSUPP;
	...
}

Root Cause Analysis
The bug constitutes a NULL pointer dereference explicitly triggered within `__ethtool_get_link_ksettings()`. Because the API is exported for transparent kernel-centric consumption (e.g. by `ib_get_eth_speed`), it bypasses the robust validation standard userspace calls experience via the `ethtool_ioctl` ioctl wrapper, completely overlooking empty/NULL `dev->ethtool_ops` arrays.

When `ipvlan` bridges the request down to an unyielding backend host (`ipvlan->phy_dev`), and the host operates as a virtual loop or dummy lacking any registered `ethtool_ops`, the fetch targets `dev->ethtool_ops->get_link_ksettings`. Based on the API's pointer offset in `include/linux/ethtool.h`, this lands precisely at structural index `0x1F8`, culminating in a fatal supervisor read fault.
Unfortunately, we were unable to generate a reproducer for this bug.

Potential Impact
This memory management gap presents a local kernel panic/Denial of Service (DoS). It manifests silently anytime nested virtual abstractions process asynchronous traffic events requiring network speed capabilities over missing handler arrays, particularly through automated RDMA/IB device initializations.

Proposed Fix
To universally intercept the validation lapse inside the exported generic handler, we suggest introducing a preliminary null-check protecting the interface invocations:

--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -440,7 +440,7 @@ int __ethtool_get_link_ksettings(struct net_device *dev,
  {
  	ASSERT_RTNL();
  
-	if (!dev->ethtool_ops->get_link_ksettings)
+	if (!dev->ethtool_ops || !dev->ethtool_ops->get_link_ksettings)
  		return -EOPNOTSUPP;
  
  	if (!netif_device_present(dev))

We would be highly honored if this could be of any help.

Best regards,
RacePilot Team

Thanks for the report.

The root cause is a use-after-free of ipvlan->phy_dev, not a simple missing
NULL check on ethtool_ops.

In ib_get_eth_speed(), ib_device_get_netdev() obtains a reference to the
ipvlan device *outside* of rtnl_lock(). This creates a race window where
the underlying phy_dev can be unregistered and freed before rtnl_lock() 
is acquired.

Then recurses through ipvlan_ethtool_get_link_ksettings()
into phy_dev, it dereferences freed memory — which happens to read as 
NULL for
ethtool_ops, causing the crash at offset 0x1f8.

Diff below:

diff --git a/drivers/infiniband/core/verbs.c 

b/drivers/infiniband/core/verbs.c
index 575b4a4b200b..f16d11e7c2e3 100644

--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c

@@ -2046,11 +2046,13 @@ int ib_get_eth_speed(struct ib_device *dev, u32 

port_num, u16 *speed, u8 *width)
         if (rdma_port_get_link_layer(dev, port_num) != 
IB_LINK_LAYER_ETHERNET)
                 return -EINVAL;

+       rtnl_lock();
         netdev = ib_device_get_netdev(dev, port_num);
-       if (!netdev)
+       if (!netdev) {
+               rtnl_unlock();
                 return -ENODEV;
+       }

-       rtnl_lock();
         rc = __ethtool_get_link_ksettings(netdev, &lksettings);
         rtnl_unlock();