Hello,
syzbot found the following issue on:
HEAD commit: faf68e3523c2 Merge tag 'kbuild-fixes-v6.1-4' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11078bc5880000
kernel config: https://syzkaller.appspot.com/x/.config?x=436ee340148d5197
dashboard link: https://syzkaller.appspot.com/bug?extid=c319bb5b1014113a92cf
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4aefb045a8ae/disk-faf68e35.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c799b03718cc/vmlinux-faf68e35.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3f6af9278460/bzImage-faf68e35.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
======================================================
WARNING: possible circular locking dependency detected
6.1.0-rc6-syzkaller-00315-gfaf68e3523c2 #0 Not tainted
------------------------------------------------------
syz-executor.3/21593 is trying to acquire lock:
ffff888027069718 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0xa9/0x180 mm/memory.c:5645
but task is already holding lock:
ffff8880a24f2090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x79/0x100 fs/reiserfs/lock.c:27
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sbi->lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x12f/0x1360 kernel/locking/mutex.c:747
reiserfs_write_lock+0x79/0x100 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xd2/0x260 fs/reiserfs/super.c:704
__mark_inode_dirty+0x247/0x11e0 fs/fs-writeback.c:2408
generic_update_time fs/inode.c:1859 [inline]
inode_update_time fs/inode.c:1872 [inline]
touch_atime+0x641/0x700 fs/inode.c:1944
file_accessed include/linux/fs.h:2521 [inline]
generic_file_mmap+0x119/0x150 mm/filemap.c:3454
call_mmap include/linux/fs.h:2196 [inline]
mmap_region+0x6c3/0x1dd0 mm/mmap.c:2625
do_mmap+0x831/0xf60 mm/mmap.c:1412
vm_mmap_pgoff+0x1af/0x280 mm/util.c:520
ksys_mmap_pgoff+0x41f/0x5a0 mm/mmap.c:1458
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
-> #0 (&mm->mmap_lock#2){++++}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain kernel/locking/lockdep.c:3831 [inline]
__lock_acquire+0x2a43/0x56d0 kernel/locking/lockdep.c:5055
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x1e3/0x630 kernel/locking/lockdep.c:5633
__might_fault mm/memory.c:5646 [inline]
__might_fault+0x10c/0x180 mm/memory.c:5639
reiserfs_ioctl+0x1d2/0x330 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sbi->lock);
lock(&mm->mmap_lock#2);
lock(&sbi->lock);
lock(&mm->mmap_lock#2);
*** DEADLOCK ***
1 lock held by syz-executor.3/21593:
#0: ffff8880a24f2090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x79/0x100 fs/reiserfs/lock.c:27
stack backtrace:
CPU: 0 PID: 21593 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00315-gfaf68e3523c2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
check_noncircular+0x25f/0x2e0 kernel/locking/lockdep.c:2177
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain kernel/locking/lockdep.c:3831 [inline]
__lock_acquire+0x2a43/0x56d0 kernel/locking/lockdep.c:5055
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x1e3/0x630 kernel/locking/lockdep.c:5633
__might_fault mm/memory.c:5646 [inline]
__might_fault+0x10c/0x180 mm/memory.c:5639
reiserfs_ioctl+0x1d2/0x330 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f5a0608c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5a06d55168 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f5a061ac050 RCX: 00007f5a0608c0d9
RDX: 00000000200001c0 RSI: 0000000080087601 RDI: 0000000000000007
RBP: 00007f5a060e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffdba33ed3f R14: 00007f5a06d55300 R15: 0000000000022000
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot has found a reproducer for the following issue on:
HEAD commit: e40939bbfc68 Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=1070f4bca80000
kernel config: https://syzkaller.appspot.com/x/.config?x=c84f463eb74eab24
dashboard link: https://syzkaller.appspot.com/bug?extid=c319bb5b1014113a92cf
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=112c37e2a80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e4c2daa80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/257596b75aaf/disk-e40939bb.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9c75b8d61081/vmlinux-e40939bb.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8f0233129f4f/Image-e40939bb.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/05e314af739c/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
======================================================
WARNING: possible circular locking dependency detected
6.4.0-rc7-syzkaller-ge40939bbfc68 #0 Not tainted
------------------------------------------------------
syz-executor365/5984 is trying to acquire lock:
ffff0000db0d17d8 (&mm->mmap_lock
){++++}-{3:3}, at: __might_fault+0x9c/0x124 mm/memory.c:5731
but task is already holding lock:
ffff0000c2367090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x7c/0xe8 fs/reiserfs/lock.c:27
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sbi->lock){+.+.}-{3:3}:
__mutex_lock_common+0x190/0x21a0 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:799
reiserfs_write_lock+0x7c/0xe8 fs/reiserfs/lock.c:27
reiserfs_dirty_inode+0xe4/0x204 fs/reiserfs/super.c:704
__mark_inode_dirty+0x2b0/0x10f4 fs/fs-writeback.c:2424
generic_update_time fs/inode.c:1859 [inline]
inode_update_time fs/inode.c:1872 [inline]
touch_atime+0x5d8/0x8d4 fs/inode.c:1944
file_accessed include/linux/fs.h:2198 [inline]
generic_file_mmap+0xb0/0x11c mm/filemap.c:3606
call_mmap include/linux/fs.h:1873 [inline]
mmap_region+0xc00/0x1aa4 mm/mmap.c:2649
do_mmap+0xa00/0x1108 mm/mmap.c:1394
vm_mmap_pgoff+0x198/0x3b8 mm/util.c:543
ksys_mmap_pgoff+0x3c8/0x5b0 mm/mmap.c:1440
__do_sys_mmap arch/arm64/kernel/sys.c:28 [inline]
__se_sys_mmap arch/arm64/kernel/sys.c:21 [inline]
__arm64_sys_mmap+0xf8/0x110 arch/arm64/kernel/sys.c:21
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
-> #0 (&mm->mmap_lock){++++}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3113 [inline]
check_prevs_add kernel/locking/lockdep.c:3232 [inline]
validate_chain kernel/locking/lockdep.c:3847 [inline]
__lock_acquire+0x3308/0x7604 kernel/locking/lockdep.c:5088
lock_acquire+0x23c/0x71c kernel/locking/lockdep.c:5705
__might_fault+0xc4/0x124 mm/memory.c:5732
reiserfs_ioctl+0x10c/0x454 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sbi->lock);
lock(&mm->mmap_lock);
lock(&sbi->lock);
rlock(&mm->mmap_lock);
*** DEADLOCK ***
1 lock held by syz-executor365/5984:
#0: ffff0000c2367090 (&sbi->lock){+.+.}-{3:3}, at: reiserfs_write_lock+0x7c/0xe8 fs/reiserfs/lock.c:27
stack backtrace:
CPU: 1 PID: 5984 Comm: syz-executor365 Not tainted 6.4.0-rc7-syzkaller-ge40939bbfc68 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
dump_stack+0x1c/0x28 lib/dump_stack.c:113
print_circular_bug+0x150/0x1b8 kernel/locking/lockdep.c:2066
check_noncircular+0x2cc/0x378 kernel/locking/lockdep.c:2188
check_prev_add kernel/locking/lockdep.c:3113 [inline]
check_prevs_add kernel/locking/lockdep.c:3232 [inline]
validate_chain kernel/locking/lockdep.c:3847 [inline]
__lock_acquire+0x3308/0x7604 kernel/locking/lockdep.c:5088
lock_acquire+0x23c/0x71c kernel/locking/lockdep.c:5705
__might_fault+0xc4/0x124 mm/memory.c:5732
reiserfs_ioctl+0x10c/0x454 fs/reiserfs/ioctl.c:96
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191
el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
---
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.
syzbot has bisected this issue to:
commit d82dcd9e21b77d338dc4875f3d4111f0db314a7c
Author: Roberto Sassu <[email protected]>
Date: Fri Mar 31 12:32:18 2023 +0000
reiserfs: Add security prefix to xattr name in reiserfs_security_write()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14d0b787680000
start commit: 90b0c2b2edd1 Merge tag 'pinctrl-v6.7-1' of git://git.kerne..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=16d0b787680000
console output: https://syzkaller.appspot.com/x/log.txt?x=12d0b787680000
kernel config: https://syzkaller.appspot.com/x/.config?x=93ac5233c138249e
dashboard link: https://syzkaller.appspot.com/bug?extid=c319bb5b1014113a92cf
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113f3717680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=154985ef680000
Reported-by: [email protected]
Fixes: d82dcd9e21b7 ("reiserfs: Add security prefix to xattr name in reiserfs_security_write()")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
On Mon, Nov 6, 2023 at 3:34 AM syzbot
<[email protected]> wrote:
>
> syzbot has bisected this issue to:
>
> commit d82dcd9e21b77d338dc4875f3d4111f0db314a7c
> Author: Roberto Sassu <[email protected]>
> Date: Fri Mar 31 12:32:18 2023 +0000
>
> reiserfs: Add security prefix to xattr name in reiserfs_security_write()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14d0b787680000
> start commit: 90b0c2b2edd1 Merge tag 'pinctrl-v6.7-1' of git://git.kerne..
> git tree: upstream
> final oops: https://syzkaller.appspot.com/x/report.txt?x=16d0b787680000
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d0b787680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=93ac5233c138249e
> dashboard link: https://syzkaller.appspot.com/bug?extid=c319bb5b1014113a92cf
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113f3717680000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=154985ef680000
>
> Reported-by: [email protected]
> Fixes: d82dcd9e21b7 ("reiserfs: Add security prefix to xattr name in reiserfs_security_write()")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Hi Roberto,
I know you were looking at this over the summer[1], did you ever find
a resolution to this? If not, what do you think of just dropping
security xattr support on reiserfs? Normally that wouldn't be
something we could consider, but given the likelihood that this hadn't
been working in *years* (if ever), and reiserfs is deprecated, I think
this is a viable option if there isn't an obvious fix.
[1] https://lore.kernel.org/linux-security-module/CAHC9VhTM0a7jnhxpCyonepcfWbnG-OJbbLpjQi68gL2GVnKSRg@mail.gmail.com/
--
paul-moore.com
syzbot suspects this issue was fixed by commit:
commit 6f861765464f43a71462d52026fbddfc858239a5
Author: Jan Kara <[email protected]>
Date: Wed Nov 1 17:43:10 2023 +0000
fs: Block writes to mounted block devices
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11750da6180000
start commit: 90b0c2b2edd1 Merge tag 'pinctrl-v6.7-1' of git://git.kerne..
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=93ac5233c138249e
dashboard link: https://syzkaller.appspot.com/bug?extid=c319bb5b1014113a92cf
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=113f3717680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=154985ef680000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: fs: Block writes to mounted block devices
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
#syz fix: fs: Block writes to mounted block devices