Description

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Reject unregistering netdevs in ib_get_eth_speed 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. Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-10-06T09:18:29.660Z",
  "pubdate": "2026-10-06T09:18:29.660Z",
  "executiveSummary": "This vulnerability involves a use-after-free condition within the Linux kernel's RDMA subsystem, specifically triggered during the interaction between RDMA port queries and unregistering network devices.\nThe flaw originates from ib_get_eth_speed() failing to validate the registration state of a net_device object before invoking its ethtool operations.\nAlthough ib_device_get_netdev() returns a referenced object, this reference only guarantees memory persistence rather than functional readiness, allowing operational callbacks to execute on net_devices that have already undergone NETDEV_UNREGISTER and ndo_uninit phases.\nAn attacker capable of triggering asynchronous RDMA port queries may exploit this race condition to induce kernel-level memory corruption or system crashes.\nThe vulnerability affects the RDMA core subsystem when interacting with network devices. The primary risk is local denial-of-service or potential elevation of privilege depending on the state of the netdev object during the race window.",
  "technicalDetails": "The vulnerability resides in the ib_get_eth_speed() function within the RDMA/core component of the Linux kernel. The root cause is a synchronization mismatch between the reference counting mechanism of net_device objects and their operational lifecycle state.\nWhen ib_device_get_netdev() is called, it returns a referenced pointer to a net_device structure. The intention of this design is to ensure the struct remains allocated for cleanup purposes; however, it does not imply that the interface is still functional. The function ib_get_eth_speed() improperly proceeds to call the ethtool callback associated with the net_device without checking if the device has already been marked as unregistered.\nThe attack flow follows a race condition pattern: 1) A legitimate RDMA port query initiates. 2) The system triggers an unregistration event for the associated network interface (NETDEV_UNREGISTER and ndo_uninit). 3) Because the ib_get_eth_speed() function lacks a registration state check, it proceeds to access the netdev object's callback table even after the underlying infrastructure has been torn down. 4) By the time the ethtool operation is invoked, the device context may be invalid or partially deinitialized, leading to a use-after-free or a null pointer dereference.\nThe fix requires holding the RTNL (rtnl_link_lock) across both the registration state verification and the ethtool operation. By verifying NETREG_REGISTERED under the RTNL lock, the kernel ensures that the unregistration process cannot start or complete while the ethtool callback is in progress. The reference drop must be deferred until after the RTNL lock is released and the device access is fully concluded to ensure atomicity of the verification and execution phases.\nExploitation requires an attacker to successfully time an asynchronous RDMA query to coincide with the teardown of a netdev object. Successful exploitation generally results in a kernel panic, but could potentially be leveraged for controlled memory access if the ethtool callback structures are manipulated or reclaimed by other kernel allocations during the race window."
}