From nobody Fri Sep 25 09:26:34 2026 Received: from mail-wm2-f13.google.com (mail-wm2-f13.google.com [74.125.225.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87BE8442FBE for ; Mon, 14 Sep 2026 20:42:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.141 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789418526; cv=none; b=iQhuX2E0qDJosjuklnNF/LNE3lOs/KzJHnafrYP8xgUrIM3nYn8ZZgVu2LVXwhe9S+gzJGKOBUWlUpKXrmt8RYqGLFjaPHt+I/F27MIlz3hsXdwZmeMSUW9HnUY4uPHQeIAYWCoGlo3EfGmMIntVchhtgDjVYaBv7a9sHsJr4II= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789418526; c=relaxed/simple; bh=q/gYZaKPHkpl+flr9yB4ZcLhD4w9vAlah4ZGjxaGfEs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=PAZ/Kjf6tL/cwO2B1BiGkWw8df6U9pnKpk5IohJdYoL/QYcIx6bRJ7fnduiaLngqa9Gzs6kgFoS/k+f7K99xK4pVAVXPxs2tE2ee+XzD0B3zcLqZkpIjS4xbn0DdZzfJPAZoblzn00/P29B7KFlt1XU5HO1OiRia3ESaquE46H8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la; spf=pass smtp.mailfrom=lex.la; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b=MyNa18DR; arc=none smtp.client-ip=74.125.225.141 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lex.la Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lex.la Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lex.la header.i=@lex.la header.b="MyNa18DR" Received: by mail-wm2-f13.google.com with SMTP id 5b1f17b1804b1-49e7d2bb404so1638435e9.1 for ; Mon, 14 Sep 2026 13:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lex.la; s=google; t=1789418523; x=1790023323; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=YIgW9/qxzwAGmM0KAqA0Ke4KQST+4RHZujJdgneRY1A=; b=MyNa18DRkrWPHi55lCVSE/4T9O9QgqtwgS0+t/eBMVT+eujyuzdlBcHAbnxp6IONU8 QJMwWyjW2qsXlzneAGr8kUr/5rAj0SudwFyslTFQXwgn2atq9Gl4CyjF9sKhOihagrBy uCPO/6g7plinb4yFAFIKVOS01Ebx7kR9zmuKLkvjKwTRAMeTGWKUmevjZxc8dBdgMQ6K ai1+kICA9bUAUh2Eqs5x2KEFh4/89xEl25Q93au8Z7+klRlgvj0RoxX5NfRZ0ss9K5Xu zufpML7Y6puYL6ne3I4DcXFKEp1Q0IE3vfBwIYSnqFKuHY8s6WfZeDGOD9UKxvGAkodq mJCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789418523; x=1790023323; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=YIgW9/qxzwAGmM0KAqA0Ke4KQST+4RHZujJdgneRY1A=; b=eC3VrQe1lhaMcoHuMpgUY0nlltOzgZ6CsdsWZcS5nMOAKFFg3lP2sRJCkhjp7vnAYf MySFvf9MjxXzhOWWIe0qxfhs+2BhFdFSJIeqn2fsGH8za27TxVnLcxPnzEagCnWOp581 7aetzbldfzsXIEV5yTU1DesSx4RE6fj4ne8GseOEFaUn3Iml5EZhcwKCB9LOBJ1QHc3e Z3vrN67+cr/dSp+T4XIpdc7NnQdtCOtgeZ3iUMdkUV60WJBGwiL7eFqr5EQCN4hSztDs C9ICJYyqXDU7XTvJepk9oqYaOFzONHgbj6izMIlm7jqEkcHCyyN44O4d08shMTcIKqA6 WdOA== X-Forwarded-Encrypted: i=1; AKwUvBzrVXhDpog1oU9cMrv3N3WBHw8l2j0kfe5GcrAXkG61arKJ+t/ZCbsWrLemSJkgxraF4jaaK2TWlIGiKx4=@vger.kernel.org X-Gm-Message-State: AFuF++l4X5cjQp9anOe0MPvftBKcykhZM+W5+Qk4Yx76kTDvlfOuaJ19 9DdQFUG45JuYaRmQ9J38CNezksEDC+wrv9Gn5MyXXvxZf5VEgmDvnlnKEkUHFBac5dk= X-Gm-Gg: AYBFou1PhiPzpHTlKJUuUJg2gKN/dSxgGg8sQG81JRBznlxdVsQ+XnmMi0APFp/xL/C rLMDL00LIHPU+6efB/xQayGaGh3gwhtcw7rrycEVylaCllPXZXOVNmKJSmVGoeaX0fZjE3IzHgd ZH5gei5FddmQzmo8AO2AM4lHV68p5aRWxJ7vL7G2Rf1stFu++RizchiYp/ERaB9IO4i9eI9Gt0i 4lCqYH23Rn8iWEwXOpCAEbsAf3UpKfh84qysgDB1fWOEqGpkQdn7XkapxHcbHDhiogRaagyZbzf 6ho9oIMIzwQUvxkkeXYp7SXhAA4jnfzZ5XaOoPKOhAojSpyNr6e5hqaLX538cLUYz2GLirK9fBQ 360psO/3FIbnlEX+vX2MpCOAiq84In5sIiJDBjUfjUYk/Lg6Q4yeNtOwGJX09SMlIBTkkxMJto/ XnqABgxs6VbiFzd8JLMczYXTzXxmhXtiZg5SytDwQmpxD9MRnqKg== X-Received: by 2002:a05:600c:4f92:b0:49e:63cc:6324 with SMTP id 5b1f17b1804b1-49e7d72afb1mr15300375e9.6.1789418522652; Mon, 14 Sep 2026 13:42:02 -0700 (PDT) Received: from remote-01 ([84.17.55.229]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7d6a8d5asm14769785e9.9.2026.09.14.13.42.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2026 13:42:02 -0700 (PDT) From: Aleksei Sviridkin To: netdev@vger.kernel.org Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org, Aleksei Sviridkin Subject: [PATCH net] net: phy: reject attach while the PHY driver is in transition Date: Mon, 14 Sep 2026 23:42:00 +0300 Message-ID: <20260914204200.2743251-1-f@lex.la> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" phy_remove() clears phydev->drv as its last act; the driver core clears d->driver only afterwards, in device_unbind_cleanup(). In that window phy_attach_direct() skips the genphy substitution, because d->driver is still set, and then dereferences the NULL phydev->drv in phy_drv_supports_irq(). Refuse the attach there, before any reference on the driver is taken. The function holds no lock over phydev->drv, and it cannot hold device_lock across the attach: for a genphy-substituted PHY its error path reaches device_release_driver() on the same device, which takes that lock again. So this closes the case where the unbind is already in flight; an unbind starting mid-attach still races. Failing beats falling back to polling: phylink_bringup_phy() dereferences phy->drv right after a successful attach, and a continued attach would already hold the driver module reference that phy_detach() drops only while d->driver is set, leaking it once the unbind completes. -ENODEV is wrong: DSA takes it as permission to look for the PHY on the switch's internal MDIO bus. Fixes: 61c81872815f ("net: phy: phy_device: Prevent nullptr exceptions on I= SR") Assisted-by: LLM Signed-off-by: Aleksei Sviridkin --- Notes: Found by reading the unbind path, not from a crash report: phy_remove() clears phydev->drv before the driver core clears d->driver, while phy_attach_direct() keys its genphy substitution off d->driver. =20 Verified on an MT7981 board (mtk_eth_soc GMAC, "MediaTek MT7981 PHY" at mdio-bus:00), 6.18.44, with a 200 ms msleep() added at the end of phy_remove() to hold the window open. Two images, identical except for this patch. =20 Without the patch, backgrounding =20 echo mdio-bus:00 > "/sys/bus/mdio_bus/drivers/MediaTek MT7981 PHY/unb= ind" =20 and immediately running "ip link set wan up" oopses on the first attempt: =20 Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000128 pc : phy_attach_direct+0x150/0x380 Call trace: phy_attach_direct+0x150/0x380 (P) mtk_open+0x38/0xb70 =20 x0 is 0 and 0x128 is the offset of config_intr in struct phy_driver. =20 With the patch the same sequence fails the attach on the first attempt instead, "wan: mtk_open: could not attach PHY: -16", and no oops is logged. Binding the driver back and bringing the interface up afterwards succeeds with the link up, so the early return leaves the phydev reusable. An ordinary bring-up is unaffected, and with the driver left unbound the genphy substitution still runs: "PHY [mdio-bus:00] driver [Generic PHY]", link up. drivers/net/phy/phy_device.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 94b2e85e00a3..044cefd9840b 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1781,6 +1781,10 @@ int phy_attach_direct(struct net_device *dev, struct= phy_device *phydev, d->driver =3D &genphy_driver.mdiodrv.driver; =20 phydev->is_genphy_driven =3D 1; + } else if (!phydev->drv) { + /* d->driver outlives phydev->drv on unbind, precedes it on bind */ + err =3D -EBUSY; + goto error_put_device; } =20 if (!try_module_get(d->driver->owner)) { --=20 2.53.0