[PATCH net v3] RDMA/core: Reject unregistering netdevs in ib_get_eth_speed

[Krystian Kaniewski]

ib_device_get_netdev() intentionally returns a referenced net_device even
when it is unregistering, so matching and cleanup callers can still find
the association. The reference keeps struct net_device allocated, but does
not guarantee that the device remains operational.

ib_get_eth_speed() uses the returned device operationally by invoking its
ethtool callback. Although that call is made under RTNL, the function does
not verify the registration state first. An asynchronous RDMA port query
can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit
have completed.

Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a
device which is being unregistered. Keeping RTNL across the check and the
ethtool operation prevents unregister from starting between them.

Also copy the device name before dropping the reference, since the warning
path currently dereferences netdev after dev_put().

Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev")
Reported-by: syzbot+5fe14f...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5fe14f2ff4ccbace9a26
Signed-off-by: Krystian Kaniewski <krystianm...@gmail.com>
---
v3:
- Reworked the fix following Jakub Kicinski's review: a netdev
reference protects the allocation, not the operational lifetime.
- Moved the fix from ipvlan to the operational RDMA caller.
- Check NETREG_REGISTERED under RTNL before invoking ethtool.
- Avoid dereferencing netdev after dev_put() in the warning path.
- Added the RDMA maintainers and mailing list.
v2: https://lore.kernel.org/all/20260803121140.261329...@gmail.com/

drivers/infiniband/core/verbs.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 86811d31092c..d50e761be4c8 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -2040,6 +2040,7 @@ int ib_get_eth_speed(struct ib_device *dev, u32 port_num, u16 *speed, u8 *width)
u32 netdev_speed;
struct net_device *netdev;
struct ethtool_link_ksettings lksettings = {};
+ char name[IFNAMSIZ];

if (rdma_port_get_link_layer(dev, port_num) != IB_LINK_LAYER_ETHERNET)
return -EINVAL;
@@ -2049,7 +2050,15 @@ int ib_get_eth_speed(struct ib_device *dev, u32 port_num, u16 *speed, u8 *width)
return -ENODEV;

rtnl_lock();
+ if (READ_ONCE(netdev->reg_state) != NETREG_REGISTERED) {
+ dev_put(netdev);
+ rtnl_unlock();
+ return -ENODEV;
+ }
+
rc = __ethtool_get_link_ksettings(netdev, &lksettings);
+ if (rc)
+ strscpy(name, netdev->name, sizeof(name));
rtnl_unlock();

dev_put(netdev);
@@ -2060,7 +2069,7 @@ int ib_get_eth_speed(struct ib_device *dev, u32 port_num, u16 *speed, u8 *width)
netdev_speed = SPEED_1000;
if (rc)
pr_warn("%s speed is unknown, defaulting to %u\n",
- netdev->name, netdev_speed);
+ name, netdev_speed);
}

ib_get_width_and_speed(netdev_speed, lksettings.lanes,
--
2.53.0

[Jason Gunthorpe]

On Mon, Aug 10, 2026 at 03:31:20PM +0200, Krystian Kaniewski wrote:

> @@ -2049,7 +2050,15 @@ int ib_get_eth_speed(struct ib_device *dev, u32 port_num, u16 *speed, u8 *width)
> return -ENODEV;
>
> rtnl_lock();
> + if (READ_ONCE(netdev->reg_state) != NETREG_REGISTERED) {
> + dev_put(netdev);
> + rtnl_unlock();
> + return -ENODEV;
> + }
> +
> rc = __ethtool_get_link_ksettings(netdev, &lksettings);
> + if (rc)
> + strscpy(name, netdev->name, sizeof(name));
> rtnl_unlock();
>
> dev_put(netdev);
> @@ -2060,7 +2069,7 @@ int ib_get_eth_speed(struct ib_device *dev, u32 port_num, u16 *speed, u8 *width)
> netdev_speed = SPEED_1000;
> if (rc)
> pr_warn("%s speed is unknown, defaulting to %u\n",
> - netdev->name, netdev_speed);
> + name, netdev_speed);
> }

I would probably just put this block inside the rtnl lock and not copy
the netdev->name

Jason

[Jakub Kicinski]

On Mon, 10 Aug 2026 15:31:20 +0200 Krystian Kaniewski wrote:
> Subject: [PATCH net v3] RDMA/core: Reject unregistering netdevs in ib_get_eth_speed

nit: Please don't tag as [PATCH net], networking maintainers don't
normally touch RDMA patches.

[Jason Gunthorpe]

I also drop all patches tagged like this from the patchworks sight
unseen.

Jason

[Krystian Kaniewski]

Thanks for your comments. It's my first contribution really, so I'm
still learning on how to do it properly.

I'll do the requested changes by both of you.

Should I rebase the v4 patch on top of any specific branches for rdma?

I found "for-rc" branch while looking at
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git, would it
be a good target?

[Jason Gunthorpe]

On Tue, Aug 11, 2026 at 11:21:19AM +0200, Krystian Kaniewski wrote:
> Thanks for your comments. It's my first contribution really, so I'm still
> learning on how to do it properly.
>
> I'll do the requested changes by both of you.
>
> Should I rebase the v4 patch on top of any specific branches for rdma?
>
> I found "for-rc" branch while looking at
> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git, would it be a
> good target?

At this point the for-next branch is a better choice

Jason