Re: BUG: unable to handle kernel NULL pointer dereference in __ethtool_get_link_ksettings
From: Jiayuan Chen
Date: Wed Mar 11 2026 - 05:13:42 EST
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:
```c
// 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:
```c
// 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:
```diff
--- 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();