From: syzbot <syzbot+d2085ac2d653b9e383e2@syzkaller.appspotmail.com>
To: a.hindborg@kernel.org, dmitry.kasatkin@gmail.com,
eric.snowberg@oracle.com, jmorris@namei.org, leitao@debian.org,
linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, paul@paul-moore.com,
roberto.sassu@huawei.com, serge@hallyn.com,
syzkaller-bugs@googlegroups.com, zohar@linux.ibm.com
Subject: Re: [syzbot] [integrity?] [lsm?] possible deadlock in configfs_read_iter
Date: Thu, 03 Sep 2026 01:04:35 -0700 [thread overview]
Message-ID: <6a992a13.f03f19fe.169578.0004.GAE@google.com> (raw)
In-Reply-To: <6a698f41.d9e86bb5.297b12.0052.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 940de590b839 Merge tag 'hardening-v7.3-rc2' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=164270f9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=d2085ac2d653b9e383e2
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14e850f9580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=114270f9580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-940de590.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/64f87fb4f049/vmlinux-940de590.xz
kernel image: https://storage.googleapis.com/syzbot-assets/917bd28bbd2d/bzImage-940de590.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d2085ac2d653b9e383e2@syzkaller.appspotmail.com
nvmet: adding nsid 1 to subsystem testsubsys
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.17/5927 is trying to acquire lock:
ffff88802cf0e080 (&buffer->mutex){+.+.}-{4:4}, at: configfs_read_iter+0x79/0x6f0 fs/configfs/file.c:86
but task is already holding lock:
ffff88802405fe48 (&ima_iint_mutex_key[depth]){+.+.}-{4:4}, at: process_measurement+0x5ab/0x2350 security/integrity/ima/ima_main.c:319
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&ima_iint_mutex_key[depth]){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
process_measurement+0x5ab/0x2350 security/integrity/ima/ima_main.c:319
ima_file_check+0xc3/0x110 security/integrity/ima/ima_main.c:685
security_file_post_open+0xc4/0x210 security/security.c:2755
do_open fs/namei.c:4839 [inline]
path_openat+0x5cd/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
file_open_name+0x1c3/0x3e0 fs/open.c:1375
filp_open+0x2e/0x50 fs/open.c:1392
nvmet_file_ns_enable+0x95/0x420 drivers/nvme/target/io-cmd-file.c:41
nvmet_ns_enable+0x35f/0x5d0 drivers/nvme/target/core.c:596
nvmet_ns_enable_store+0x11e/0x160 drivers/nvme/target/configfs.c:737
flush_write_buffer fs/configfs/file.c:207 [inline]
configfs_write_iter+0x302/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #2 (&subsys->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
nvmet_ns_device_path_store+0x57/0x1c0 drivers/nvme/target/configfs.c:538
flush_write_buffer fs/configfs/file.c:207 [inline]
configfs_write_iter+0x302/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (&p->frag_sem){.+.+}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
down_read+0x99/0x4c0 kernel/locking/rwsem.c:1574
flush_write_buffer fs/configfs/file.c:205 [inline]
configfs_write_iter+0x218/0x4e0 fs/configfs/file.c:229
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x6af/0x1050 fs/read_write.c:687
ksys_write+0x12a/0x250 fs/read_write.c:739
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&buffer->mutex){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5254
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
configfs_read_iter+0x79/0x6f0 fs/configfs/file.c:86
__kernel_read+0x397/0xad0 fs/read_write.c:532
integrity_kernel_read+0x7e/0xb0 security/integrity/iint.c:28
ima_calc_file_hash_tfm+0x25e/0x350 security/integrity/ima/ima_crypto.c:222
ima_calc_file_hash+0x1e3/0x380 security/integrity/ima/ima_crypto.c:280
ima_collect_measurement+0x94f/0xb30 security/integrity/ima/ima_api.c:300
process_measurement+0xdfe/0x2350 security/integrity/ima/ima_main.c:425
ima_file_check+0xc3/0x110 security/integrity/ima/ima_main.c:685
security_file_post_open+0xc4/0x210 security/security.c:2755
do_open fs/namei.c:4839 [inline]
path_openat+0x5cd/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Chain exists of:
&buffer->mutex --> &subsys->lock --> &ima_iint_mutex_key[depth]
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ima_iint_mutex_key[depth]);
lock(&subsys->lock);
lock(&ima_iint_mutex_key[depth]);
lock(&buffer->mutex);
*** DEADLOCK ***
locks held by syz.0.17/5927: 1, last CPU#3:
#0: ffff88802405fe48 (&ima_iint_mutex_key[depth]){+.+.}-{4:4}, at: process_measurement+0x5ab/0x2350 security/integrity/ima/ima_main.c:319
stack backtrace:
CPU: 3 UID: 0 PID: 5927 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2059
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2191
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5254
lock_acquire kernel/locking/lockdep.c:5908 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5865
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
configfs_read_iter+0x79/0x6f0 fs/configfs/file.c:86
__kernel_read+0x397/0xad0 fs/read_write.c:532
integrity_kernel_read+0x7e/0xb0 security/integrity/iint.c:28
ima_calc_file_hash_tfm+0x25e/0x350 security/integrity/ima/ima_crypto.c:222
ima_calc_file_hash+0x1e3/0x380 security/integrity/ima/ima_crypto.c:280
ima_collect_measurement+0x94f/0xb30 security/integrity/ima/ima_api.c:300
process_measurement+0xdfe/0x2350 security/integrity/ima/ima_main.c:425
ima_file_check+0xc3/0x110 security/integrity/ima/ima_main.c:685
security_file_post_open+0xc4/0x210 security/security.c:2755
do_open fs/namei.c:4839 [inline]
path_openat+0x5cd/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f57f139e159
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd81407e38 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f57f1625fa0 RCX: 00007f57f139e159
RDX: 0000000000000002 RSI: 0000200000000240 RDI: ffffffffffffff9c
RBP: 00007f57f1435024 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f57f1625fac R14: 00007f57f1625fa0 R15: 00007f57f1625fa0
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
prev parent reply other threads:[~2026-09-03 8:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 5:27 [syzbot] [fs?] possible deadlock in configfs_read_iter syzbot
2026-09-03 8:04 ` syzbot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a992a13.f03f19fe.169578.0004.GAE@google.com \
--to=syzbot+d2085ac2d653b9e383e2@syzkaller.appspotmail.com \
--cc=a.hindborg@kernel.org \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jmorris@namei.org \
--cc=leitao@debian.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.