From nobody Thu Apr 9 03:28:35 2026 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA2E73B2FE3; Wed, 11 Mar 2026 08:12:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773216778; cv=none; b=HNZ/hRhoTlfgjTA6poomeTOfTDlF7hvQd0QT1SDuy20u3EtM6ftZ9swI5lKtc1JFlid39CS88FZa4qo99tULcOq2FFHyFj93L5SW8uYkHWGjCWFSvJ3h09CjCyOG+u8xxqk3k/tsHnjzlbEmZDkhvzImBPqFVqSnREQnxZ3LoOs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773216778; c=relaxed/simple; bh=+28AbaM0l2llSpXWK3HnSybGAcgjB1fHNFeeA5L0FRY=; h=Date:From:To:Subject:Content-Type:MIME-Version:Message-ID; b=P8a3UwoYYU433RPU49jl3El640XM4mb6RLSArXhveiN98TtoTGfP+I3NLEYUl4pHAySIuWk8DC0Q0vuqJZ0obc5Zv/s45Alw6QPXFvRT5KUf47L4RDVSIvFJCjGlhwqgexjnUPsqek6DIReywj7rAPN7TubY7+LZ2MsrA+wwFXc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=ncH7FfqZ; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="ncH7FfqZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:To:Subject:Content-Type:MIME-Version: Message-ID; bh=+28AbaM0l2llSpXWK3HnSybGAcgjB1fHNFeeA5L0FRY=; b=n cH7FfqZE2Cxhx1Myi1PO8ZPQLi3DSfumgw6OByZlp6QdItra040iEb2ng1rcRmUz Chf5CYOrnuWK7BkzjHiXo7gRIDQJVzxadyKJR2j3AF74rMWzdkpFXlgU9MX2hRu+ pyhAVdb1E69BxFFRsI1T1Qw92/OdzLO6R5wwGGgewY= Received: from luckd0g$163.com ( [183.205.138.18] ) by ajax-webmail-wmsvr-40-127 (Coremail) ; Wed, 11 Mar 2026 16:11:56 +0800 (CST) Date: Wed, 11 Mar 2026 16:11:56 +0800 (CST) From: "Jianzhou Zhao" To: edumazet@google.com, davem@davemloft.net, andrew+netdev@lunn.ch, kuba@kernel.org, pabeni@redhat.com, sdf@fomichev.me, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: BUG: unable to handle kernel NULL pointer dereference in __ethtool_get_link_ksettings X-Priority: 3 X-Mailer: Coremail Webmail Server Version 2023.4-cmXT build 20251222(83accb85) Copyright (c) 2002-2026 www.mailtech.cn 163com X-NTES-SC: AL_Qu2cAf6auU8q4CSYYOkfmU4Rhug7UMO3uf8n24JfPJ9wjA/p2yseUUF9NmPf88CwFTuXvxiGfTNO1/ZAU5BifrwxKbrooSbP2rWJsszDrrclvA== Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: X-Coremail-Locale: zh_CN X-CM-TRANSID: fygvCgCXFbnMI7FpAcd2AA--.39000W X-CM-SenderInfo: poxfyvkqj6il2tof0z/xtbC9gzCTWmxI8wh8wAA3Q X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset="utf-8" Subject: [BUG] net: kernel NULL pointer dereference in __ethtool_get_link_k= settings Dear Maintainers, We are writing to report a NULL pointer dereference vulnerability within th= e `__ethtool_get_link_ksettings()` function. This bug was found by our cust= om fuzzing tool, RacePilot. The bug occurs when an internal subsystem (e.g.= , `smc` routing or `infiniband` querying a hardware port) attempts to retri= eve the link speed of an `ipvlan` interface that is layered on top of a vir= tual or device hierarchy lacking `ethtool_ops`. We observed this bug on the= Linux kernel version 6.18.0-08691-g2061f18ad76e-dirty. Call Trace & Context =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=20 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 8322 Comm: kworker/0:9 Not tainted 6.18.0-08691-g2061f18= ad76e-dirty #50 PREEMPT(voluntary)=20 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: 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 ... =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Execution Flow & Code Context When backend kernel systems like infiniband (`ib_get_eth_speed`) call `__et= htool_get_link_ksettings()` on a top-level `ipvlan` device to evaluate unde= rlying ethernet capabilities, the execution delegates successfully through = the device's mapped proxy routine. However, `ipvlan` triggers a nested fall= back 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 =3D netdev_priv(dev); return __ethtool_get_link_ksettings(ipvlan->phy_dev, cmd); // <-- Nested f= allback 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 transpare= nt kernel-centric consumption (e.g. by `ib_get_eth_speed`), it bypasses the= robust validation standard userspace calls experience via the `ethtool_ioc= tl` ioctl wrapper, completely overlooking empty/NULL `dev->ethtool_ops` arr= ays.=20 When `ipvlan` bridges the request down to an unyielding backend host (`ipvl= an->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_ks= ettings`. Based on the API's pointer offset in `include/linux/ethtool.h`, t= his lands precisely at structural index `0x1F8`, culminating in a fatal sup= ervisor 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 as= ynchronous traffic events requiring network speed capabilities over missing= handler arrays, particularly through automated RDMA/IB device initializati= ons. Proposed Fix To universally intercept the validation lapse inside the exported generic h= andler, we suggest introducing a preliminary null-check protecting the inte= rface 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(); =20 - if (!dev->ethtool_ops->get_link_ksettings) + if (!dev->ethtool_ops || !dev->ethtool_ops->get_link_ksettings) return -EOPNOTSUPP; =20 if (!netif_device_present(dev)) ``` We would be highly honored if this could be of any help. Best regards, RacePilot Team