From nobody Thu Apr 2 00:15:31 2026 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 1F0044A32 for ; Mon, 16 Feb 2026 06:20:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771222828; cv=none; b=W1l4HsJ/Za1QcpYzD1lTgpocFzyQZB386yzUDc+MGltePqZaSWlEP13JSsf0+z+9y1w0YtntgRsPHFj4e95vLRUSXcxn7gz3V5xUo/8d/yClcYK5BjmRrgnbZMuZBq8vBeDJ5lZrycMi5uMDVfcdhLFtcwMNq6OqS+cmXHI9/r8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771222828; c=relaxed/simple; bh=lweh5wTqdn5NyXCEB1iITaZxpjD9zsXuEt4pDx+EBK4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=BOY1VJlQqFW2cGbLWKQ1K22LYoV3cKJYcPc19lTQC1N23l7plD2XCVs/8MUU8MeJCWWMI8d6vIvAdyOJr0WuQY3xNFCDrE8YkVsjlMp7+bo9XERrLx323uDdo/66TCKTDfQQWm3plKJayJAcpHZ7jcI7q2mjZBYkOX80ekxtMdw= 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=ALAEpDBW; arc=none smtp.client-ip=209.85.210.169 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="ALAEpDBW" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-8217f2ad01eso2314652b3a.2 for ; Sun, 15 Feb 2026 22:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771222826; x=1771827626; 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; bh=gq3u6/pH6XaIhkLYyxC209miQpGjF2eS8OFp0J3cin8=; b=ALAEpDBWJxUjzuwSWKAnp/tMqGNmMxFuwNAjeuQXGFVfxHaXlhJ+ZT8cxJX/qPwao/ hYz0pxajX5pN/xjXORvEfNN8AMMFd1LiRivuBTmv693BuH7gqJwWHgcVVtwgqwvgxQn0 x2h9k0gSCiHgWYDMOXBhrU9pbVgRj8k42Z3X325TwHdOLJQg+/9BMlq0X69+nC8M/NNb gy63Ha8sdQnw+PL5ePrmGT6RaMGKuQbCtxmQxVgy6y0HaHfmJ2rOagsVynAN6t27zh7F TMXqpTMeTHwOqXee/2AhBRUwg9lVJEzsXhkWbY3XvE2l2OLfNOxJW9IRe5Phn+xYd33u MwzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771222826; x=1771827626; 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; bh=gq3u6/pH6XaIhkLYyxC209miQpGjF2eS8OFp0J3cin8=; b=Ty8SUAX4aY4en1KUxzEdhPRraD/vG2LLQv9f8baTlZKAbuB+7YEIqY15MNuFibS6UY QUJ/uFKG+D52dY5xpCg12QmcE04SU3/uZTGujK8J08HR7YlfoSGzxLidtVvkfaJifa/p IDMTCzbQQ/BoSL71tUmMVbtsaz3WXTVD3eM7Kld3XhbVTzIuDpyVKMtDSB3SVuzvCKe5 MJT6hdu4QTFCfKFUngFr3Lp6ybu/kY7M/rsL4oKXlsftGAvQMCcueuUOQsbDgQ1yJD7K nTkpAzNfhz9tXOPQ33I6aoPHF15LA+NYp6PGc2aGrp4Z7JW81CV7f2kE/PVo02fLiLZb +ZZA== X-Forwarded-Encrypted: i=1; AJvYcCWjlfUsKhukLxXeCi0ovpbmnL5yyQCCf+ZQC/isXKhFeY+8Fsik8NhHgZf2xi7Q5sVKbuDIjh1go3tXQss=@vger.kernel.org X-Gm-Message-State: AOJu0YxU0c6tJIQNi59DScNEZc4XVu3eq/bdTGoQFGMCx7O/X5CVZeLx n99lmwx276F2Pg0/OLkwj3Fb6u2Yjxn3gwq/s+2ZYhfHXM9VOCaFx4bY X-Gm-Gg: AZuq6aKlJ4OmVO/5NAlk8AbkusyXxLKiPyfbxbcmA5WJub14t5OG7FiDHYhs9Tgty5p ZnmW3UIsx+s/fAxSgFp9KdXbAHDlAfrWqvgfgmgdsfDRIvthDvK4W4uf3M6cWOWZAflG9Wxt1WS PngJT23BWru8pgyx0/Gvr0tEp0ZJuQ6ueBKhCMT5amo1dzMugus1OtUHs2CmmUehrNxrKdQRVPU YqCR40+AoOlxT4RdanIyJn891CtgLWxIadNotgw5IryVuNV9KLykitiD6SPAQs4aEfncKhOvBXQ tLLm3aE92jz7MfppZUy/ha1K4G56ri49gD/uAZpti7epQBpbtUb/dbUOXRCqOPlxdBjblkBpS/G wXuQC10kLNBtc8PTDukvtzm7X8JB9yE6OQwj1TgDwquc0Re/78EDZq1dDaj472wLq80m0wWa4nm idHys9mbXFdEJz5SewIRg77RKzPisYTNM3QLRq5w== X-Received: by 2002:a05:6a00:7543:b0:81e:12f1:d83 with SMTP id d2e1a72fcca58-824c6102ba1mr7161063b3a.42.1771222826432; Sun, 15 Feb 2026 22:20:26 -0800 (PST) Received: from localhost.localdomain ([114.79.136.20]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-824c6a626bfsm8992768b3a.28.2026.02.15.22.20.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 22:20:26 -0800 (PST) From: Prithvi Tambewagh To: martin.petersen@oracle.com, d.bogdanov@yadro.com, bvanassche@acm.org, viro@zeniv.linux.org.uk Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, khalid@kernel.org, Prithvi Tambewagh , syzbot+f6e8174215573a84b797@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: [PATCH v4] scsi: target: fix recursive locking in __configfs_open_file() Date: Mon, 16 Feb 2026 11:50:02 +0530 Message-Id: <20260216062002.61937-1-activprithvi@gmail.com> X-Mailer: git-send-email 2.34.1 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" In flush_write_buffer, &p->frag_sem is acquired and then the loaded store function is called, which, here, is target_core_item_dbroot_store(). This function called filp_open(), following which these functions were called (in reverse order), according to the call trace: down_read __configfs_open_file do_dentry_open vfs_open do_open path_openat do_filp_open file_open_name filp_open target_core_item_dbroot_store flush_write_buffer configfs_write_iter target_core_item_dbroot_store() tries to validate the new file path by trying to open the file path provided to it; however, in this case, the bug report shows: db_root: not a directory: /sys/kernel/config/target/dbroot indicating that the same configfs file was tried to be opened, on which it is currently working on. Thus, it is trying to acquire frag_sem semaphore of the same file of which it already holds the semaphore obtained in flush_write_buffer(), leading to acquiring the semaphore in a nested manner and a possibility of recursive locking. Fix this by modifying target_core_item_dbroot_store() to use kern_path() instead of filp_open() to avoid opening the file using filesystem-specific function __configfs_open_file(), and further modifying it to make this fix compatible. Reported-by: syzbot+f6e8174215573a84b797@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Df6e8174215573a84b797 Tested-by: syzbot+f6e8174215573a84b797@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Prithvi Tambewagh Reviewed-by: Dmitry Bogdanov --- Changes since v3: - Add LOOKUP_DIRECTORY flag in call to kern_path() so as to check presence=20 of directory checks more efficiently v3 link: https://lore.kernel.org/all/20260205162624.117957-1-activprithvi@g= mail.com/T/#m175d152067817dd6e9dc1821b6fbf626e47a4007 Note: I checked out and found that when I try to test on commit 3a8660878839faadb= 4f1a6dd72c3179c1df56787 (latest commit on which bug dashboard reports the bug on, in upstream repos= itory)=20 syzbot uses, in its kernel config: CONFIG_CC_VERSION_TEXT=3D"gcc (Debian 12.2.0-14+deb12u1) 12.2.0" Ref: https://syzkaller.appspot.com/x/.config?x=3De854293d7f44b5a5 Syzbot Reply: https://lore.kernel.org/all/6767d8ea.050a0220.226966.0021.GAE= @google.com/T/#m62bc76de5549460ae98e843bb120712548489794 While when #syz test (i.e. on HEAD commit of upstream) is used, it uses, in its kernel config: CONFIG_CC_VERSION_TEXT=3D"gcc (Debian 14.2.0-19) 14.2.0" Ref: https://syzkaller.appspot.com/x/.config?x=3D99ac58566e9eb044 Syzbot reply: https://lore.kernel.org/all/6767d8ea.050a0220.226966.0021.GAE= @google.com/T/#me8b79610e4c18a8d8a7d8d6bc249d1c7cf2f8819 However in both cases it uses: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44 Probably due to mismatch in compiler version which syzbot actually uses and=20 whats present in kernel config, the build fails for the first case. However= ,=20 the patch succeeds in fixing the bug in second case. Earlier for v1 patch (sine v2 patch involved minor change to commit message=20 and v3 involved adding a missed out Reviewed-by tag) patch the kernel build= s=20 as well as testing succeeded since syzbot used this in its kernel config: CONFIG_CC_VERSION_TEXT=3D"gcc (Debian 12.2.0-14+deb12u1) 12.2.0" as well as used the compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.4= 0=20 Changes since v2: - Add Reviewed-by tag received from Dmitry Bogdanov, which was accidentally left to be added in v2 patch. v2 link: https://lore.kernel.org/linux-scsi/20260122154051.64132-1-activpri= thvi@gmail.com/T/#u Reference for Reviewed-by Tag: https://lore.kernel.org/all/20260108191523.3= 03114-1-activprithvi@gmail.com/T/#mb22d0fc06e747e2b2df8320a15afd2a0670fd0e7 Changes since v1: - Update commit message to reflect the fact that same file, which code was=20 currently operating on, was tried to be opened again, leading to=20 acquiring the same semaphore in nested manner & possibility of recursive locking. v1 link: https://lore.kernel.org/all/20260108191523.303114-1-activprithvi@g= mail.com/T/ drivers/target/target_core_configfs.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_= core_configfs.c index b19acd662726..f94c242eff97 100644 --- a/drivers/target/target_core_configfs.c +++ b/drivers/target/target_core_configfs.c @@ -108,8 +108,8 @@ static ssize_t target_core_item_dbroot_store(struct con= fig_item *item, const char *page, size_t count) { ssize_t read_bytes; - struct file *fp; ssize_t r =3D -EINVAL; + struct path path =3D {}; =20 mutex_lock(&target_devices_lock); if (target_devices) { @@ -131,17 +131,14 @@ static ssize_t target_core_item_dbroot_store(struct c= onfig_item *item, db_root_stage[read_bytes - 1] =3D '\0'; =20 /* validate new db root before accepting it */ - fp =3D filp_open(db_root_stage, O_RDONLY, 0); - if (IS_ERR(fp)) { + r =3D kern_path(db_root_stage, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &path); + if (r) { pr_err("db_root: cannot open: %s\n", db_root_stage); + if (r =3D=3D -ENOTDIR) + pr_err("db_root: not a directory: %s\n", db_root_stage); goto unlock; } - if (!S_ISDIR(file_inode(fp)->i_mode)) { - filp_close(fp, NULL); - pr_err("db_root: not a directory: %s\n", db_root_stage); - goto unlock; - } - filp_close(fp, NULL); + path_put(&path); =20 strscpy(db_root, db_root_stage); pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root); base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 --=20 2.34.1