From nobody Sat Sep 26 10:03:32 2026 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 D40E943A7F6 for ; Wed, 2 Sep 2026 09:57:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788343079; cv=none; b=WEkwBdn9RumyMs15oLbIpnMn7z+mxUTHfiGI2cl6PBozgvMYGBPaaYSgwnbBZ8g4Vyx51qub9g3KwFiXN3y1z/u0bus7fgvc7yMw0cWIYJEK+HtCPr939EXJS0aRnxdJB87wHh3H50zchVyV1KdT25mxyxWg9xky/V/iQj/WfD0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788343079; c=relaxed/simple; bh=Rn3Ml6qD+1HHdOTjNfgj8Ak/gjAuC1HBFzLG+cdX6mw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=fxBP0dtrwx5vocq5g/RZz8sSGq+XLJ3JK0prUBvRWudDlRz8wQIvg+J5I2AREnFApT2Cc6EfmM9wy8ZyyJ+r4EWS1mWu7EmgWV4QTLmFyDooeJhxb53VROQIBjZQ8HTBUiLkXI8PYyy3EwgHWVyC+plIWqdzHDD/jnbRMGdduqM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BCW3LOeZ; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BCW3LOeZ" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-499dd4900dfso773105e9.1 for ; Wed, 02 Sep 2026 02:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788343074; x=1788947874; 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=bdTxfR9/XiBh42PkGitR6A4ZtE4V1E6y6EFDszmsd5s=; b=BCW3LOeZGqLem7DnM19NhwrgjegrdcVfE1gzXeW22UmibPhV7Sk50+UWRREKDW3PqR PR3z2Ze+y6H+MRPUEg3RjwoJdt5VlJlxWt1OcasFDgju+9s/xUleEh79t5r2Tk0UiPR4 Iw3+S6uVLVoobf8EYHGyF10Azqv2bTGn+CJ9NL9HlhjI53W/W8juwAn5wmEyq7tyEMs4 aXv/01EirO1mCkcATWxhS3fxt8AGXiglTufPXDREBzN5JceYQyIWk0JiZjzxTWnuX7yR 1ZhbXeDCzA8a7HoUQ/R0rgOL6ThKzS9A3rRWgT1UvtQ93i5tpCS/biLudr0ljZuQ9OnF nyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788343074; x=1788947874; 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=bdTxfR9/XiBh42PkGitR6A4ZtE4V1E6y6EFDszmsd5s=; b=gQullRIY+RmLk3XYZDvLOb19xaZ7I947FTP9cGZwC815EZWDVNQXiMsZNY+BJKjIPF xnDk7+Ehoe6G/959wU0BSLEyaOYFC7LkgZi8AsyV04Z+AGaPbwCBGlD5n7dVWbHaii8Q Ei5RChDY3mRnj59/MmaI0i6ZNZwL4pL8X5ZRR1/Vw5Of4yaxvdQMSqfo6lNXmJ1pXoXo 0om6QBDzGtHwu12Xaz3gTq4Z/yYNjAPGEvSs6H7A5hC5SQUg34L99LliYe6dG5yfsIqI SimgIau55WgoTa24IQbpaS8qlFzUDfUV9nEVRA+ljAhAN9TYedTx0oxHLVLqh20UEVfJ /f5A== X-Forwarded-Encrypted: i=1; AHgh+RpSdyqlBO5w1ML/c6NIi0P90yVJpIAg8POXFzdWueBrwycbHfJUoH+xERG0p01f/pwvjaJHh9lsmx8PNqM=@vger.kernel.org X-Gm-Message-State: AFuF++njB8FfSh7pqzX6kUt8B7S32PJ1awluzF5AonPw6X4etmGNnG11 19blRXaYOwGUmwkoOHGJ5DSNRyDN8mygks/RQ26AUEB7Gq+PZ8UDJIru X-Gm-Gg: AR+sD13T+p+iwi+C+aahoas769/lx0lykWi0ePDWxZ7vxqq1vhEexw3mQAJmSCSF5+8 R1hNEdwAvhce/KKGDLmAmSXn+sHoiLpGPa9jCX3z3++4dhZnNj8IhvdAsVx/tpW91bFTLUFElzV SG0fV4UDAz67QTz+S78lBMTWyKlQqB+jZLxFliDJNIf1IoILygTjc+xKxc9X8psDYiugwagl/Ut 0HAKScav5iXoiBPRAQClq5TQm2fopcEn5llHb+syA7SiUeNWQA+6pfMf+PooHTLsrQGFRo35/zU 8XW/+wDR6fSmvOBbZzza28YvzFUPY1oZ3y3AcQ5KGA8KWY/GiX8mnrCjYBpDyZ5NUofsjOlBxhz zYXUUqEIqzlH8NYEoJ56I8seZ38D78AJXNFRmOUCSWkxkVKgaLG7EUNVA2ompMmVlpY4+88PJzC 9S7vH6SFJMsTqL73wEuLilB3JXwDZJcHr7OIcjm0Y3V3bgpZVqBfWK0KbZx9n8gmzBZzIaLcK8d KBLLaPDzXFANrS0nUCSscGJrA1cuVdfrQKM4T90W0U1d59TmDP5TRly6kaYK4pi830HtMtIP5j1 ZsQJ1xZDTsmBinQ= X-Received: by 2002:a05:600c:3b03:b0:49b:910c:76fb with SMTP id 5b1f17b1804b1-49ce58252e3mr29148515e9.2.1788343073581; Wed, 02 Sep 2026 02:57:53 -0700 (PDT) Received: from pop-os.. (98.102.222.87.dynamic.jazztel.es. [87.222.102.98]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce46422desm54543615e9.1.2026.09.02.02.57.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2026 02:57:53 -0700 (PDT) From: Miguel Garcia To: netdev@vger.kernel.org Cc: Miguel Garcia , andrew@lunn.ch, jacob.e.keller@intel.com, syzbot+372a7d84708b07f64d9b@syzkaller.appspotmail.com, linux-kernel@vger.kernel.org, jiri@resnulli.us, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org Subject: [PATCH net v4] devlink: use direct firmware requests for flash updates Date: Wed, 2 Sep 2026 11:57:30 +0200 Message-ID: <20260902095739.3587287-1-miguelgarciaroman8@gmail.com> X-Mailer: git-send-email 2.43.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" request_firmware() may enter the sysfs fallback and call try_to_freeze(). Devlink invokes it while holding the instance lock, causing syzbot to report: WARNING: syz-executor/... still has locks held! Firmware flash requests already name a file provided by userspace. Use request_firmware_direct() in both flash update paths so a missing file fails immediately instead of entering the sysfs fallback. This keeps the normal devlink locking intact. On systems with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=3Dy, devlink flash can no longer obtain a missing image through that fallback. Callers still receive the existing error result, and netlink users retain the extack message. Fixes: b44cfd4f5b91 ("devlink: move request_firmware out of driver") Reported-by: syzbot+372a7d84708b07f64d9b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D372a7d84708b07f64d9b Suggested-by: Jakub Kicinski Signed-off-by: Miguel Garcia --- Changes in v4: - Resend as a new thread so patchwork and CI pick up the new revision. Changes in v3: - Use request_firmware_direct() instead of dropping the devlink instance lock, as suggested by Jakub Kicinski. - Document the resulting sysfs fallback behavior. - Rebase onto net/main at bc93419130bb. Changes in v2: - Cc Jacob Keller, author of b44cfd4f5b91, as requested by Andrew Lunn. - Keep only b44cfd4f5b91 as the Fixes tag; ed539ba614a0 provides the registration check but did not introduce the locking bug. v3: https://lore.kernel.org/r/20260901123819.2035064-1-miguelgarciaroman8@g= mail.com v2: https://lore.kernel.org/r/20260830111700.1799255-1-miguelgarciaroman8@g= mail.com v1: https://lore.kernel.org/r/20260829142525.3900565-1-miguelgarciaroman8@g= mail.com net/devlink/dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/devlink/dev.c b/net/devlink/dev.c index 55959b0ff..b85bb02a9 100644 --- a/net/devlink/dev.c +++ b/net/devlink/dev.c @@ -1169,7 +1169,7 @@ int devlink_nl_flash_update_doit(struct sk_buff *skb,= struct genl_info *info) =20 nla_file_name =3D info->attrs[DEVLINK_ATTR_FLASH_UPDATE_FILE_NAME]; file_name =3D nla_data(nla_file_name); - ret =3D request_firmware(¶ms.fw, file_name, devlink->dev); + ret =3D request_firmware_direct(¶ms.fw, file_name, devlink->dev); if (ret) { NL_SET_ERR_MSG_ATTR(info->extack, nla_file_name, "failed to locate the requested firmware file"); @@ -1245,7 +1245,7 @@ int devlink_compat_flash_update(struct devlink *devli= nk, const char *file_name) goto out_unlock; } =20 - ret =3D request_firmware(¶ms.fw, file_name, devlink->dev); + ret =3D request_firmware_direct(¶ms.fw, file_name, devlink->dev); if (ret) goto out_unlock; =20 --=20 2.43.0