From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 F17E03A0E94 for ; Tue, 17 Mar 2026 09:49:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773740963; cv=none; b=jLQetPIGAwt/6Aoj98KQN0I0659CISRqP8puuaejRR+dohahsrS2e14QkuGsfCplRyGEVtAbHMuukpAu9Zm7Ow0dD5GkjwKXDUInboem8xiV9pyGgLruJI786r2V8+Npd4hmIdgtkyZ2XOdWPTjGfIOqk9o6Ix6QenKmXxU+YEo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773740963; c=relaxed/simple; bh=ST5M2Ewq07s1JCa7AgMkHMnP9+1fRIS/TI7/2Wjvbgw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fi0X1zyo/0WAU8pucni40RE9CYnDm0Mer5A7TQEmKjfh0dcxDnxjf/tDxmD/8JxALC5TVWJOMcK34B5tBUq/2a7mmhPjQUZvob4L0VX7Lrg6uJG2TnxpMgCeJ2JsEVGa1YpR+q1PNpKiSP0zGK6dvFnPm3R656+GKatrocl8sgU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=mehyF8oF; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="mehyF8oF" Message-ID: <07b0ee06-aae7-4c48-8ac6-503ee8f8ea63@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773740950; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ST5M2Ewq07s1JCa7AgMkHMnP9+1fRIS/TI7/2Wjvbgw=; b=mehyF8oFTsntVJMHlvnIiNUjH0FSMJUagJOZMEjWl6IUqZl3lmlsz+TDxcTP1v9zaRymn/ x6StfFDAlEPF256xtn02xXMcrpeH83CSZYdbZ0if+ulY3eZLGS0AncsNLdAUG0i/D2jaOb MgwCxRrgsgNTLvRmJuo1yLMfC+aCVUg= Date: Tue, 17 Mar 2026 17:48:55 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net v1] IB/core: Fix use-after-free of ipvlan phy_dev in ib_get_eth_speed To: Leon Romanovsky Cc: linux-rdma@vger.kernel.org, netdev@vger.kernel.org, Jiayuan Chen , Jianzhou Zhao , Jason Gunthorpe , Mark Bloch , Edward Srouji , Or Har-Toov , Kalesh AP , Patrisious Haddad , Maher Sanalla , Yishai Hadas , Kees Cook , Jang Ingyu , Moni Shoua , Doug Ledford , Christian Benvenuti , Selvin Xavier , Yuval Shaia , linux-kernel@vger.kernel.org References: <20260311100313.284589-1-jiayuan.chen@linux.dev> <20260316162909.GG61385@unreal> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: <20260316162909.GG61385@unreal> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/17/26 12:29 AM, Leon Romanovsky wrote: > On Wed, Mar 11, 2026 at 06:03:08PM +0800, Jiayuan Chen wrote: >> From: Jiayuan Chen >> >> Jianzhou Zhao reported a NULL pointer dereference in >> __ethtool_get_link_ksettings [1]. The root cause is a use-after-free >> of ipvlan->phy_dev. >> >> 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: between >> ib_device_get_netdev() and rtnl_lock(), the underlying phy_dev (e.g. a >> dummy device) can be unregistered and freed by another thread. > If ib_device_get_netdev() worked as it was supposed to work, it can't. > That function grabs reference on netdev and returns or netdev with elevated > reference counter which can't be freed or returns NULL. > > Thanks > ipvlan's phy_dev is safe in the data path — TX/RX runs in softirq context with RCU protection, no lock needed per packet. The issue here is in the control path. __ethtool_get_link_ksettings() requires rtnl_lock() — all existing ethtool callers follow this: - ioctl path: rtnl_lock() is taken first, then __dev_get_by_name() looks up the dev without even holding a refcnt — relying entirely on RTNL for safety. (net/ethtool/ioctl.c:3571, 3249) - netlink path: dev is looked up with refcnt first, but the actual ethtool ops run under rtnl_lock(). (net/ethtool/netlink.c:527-533) Under RTNL, phy_dev cannot disappear because phy_dev unregistration triggers NETDEV_UNREGISTER which deletes ipvlan first — all within the same RTNL context. That's why no virtual netdev driver (ipvlan, macvlan, bond, etc.) holds an extra refcnt on the lower dev in its ethtool callbacks. ib_get_eth_speed() calls __ethtool_get_link_ksettings() under rtnl_lock(), but obtains the netdev before it. Moving the lookup inside rtnl_lock() makes the netdev resolution and ethtool call atomic w.r.t. device unregistration, consistent with how ethtool's own paths work. Thanks