[syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    7a13c14ee59d Merge tag 'for-6.15-rc4-tag' of git://git.ker..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=149171b3980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a42a9d552788177b
dashboard link: https://syzkaller.appspot.com/bug?extid=750f21d691e244b473b1
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13a101cc580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2d34ac632fce/disk-7a13c14e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2ec4e8918d72/vmlinux-7a13c14e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/43b472fdcb30/bzImage-7a13c14e.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/9edd5a22bff1/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=15a101cc580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+750f21d691e244b473b1@syzkaller.appspotmail.com

INFO: task kworker/u8:0:12 blocked for more than 143 seconds.
      Not tainted 6.15.0-rc4-syzkaller-00051-g7a13c14ee59d #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u8:0    state:D stack:22568 pid:12    tgid:12    ppid:2      task_flags:0x4208060 flags:0x00004000
Workqueue: netns cleanup_net
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5382 [inline]
 __schedule+0x168f/0x4c70 kernel/sched/core.c:6767
 __schedule_loop kernel/sched/core.c:6845 [inline]
 schedule+0x165/0x360 kernel/sched/core.c:6860
 afs_cell_purge+0x3d9/0x540 fs/afs/cell.c:893
 afs_net_exit+0x50/0x100 fs/afs/main.c:146
 ops_exit_list net/core/net_namespace.c:172 [inline]
 cleanup_net+0x717/0xbd0 net/core/net_namespace.c:654
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xadb/0x17a0 kernel/workqueue.c:3319
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Showing all locks held in the system:
3 locks held by kworker/u8:0/12:
 #0: ffff88801aef3948 ((wq_completion)netns){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3213 [inline]
 #0: ffff88801aef3948 ((wq_completion)netns){+.+.}-{0:0}, at: process_scheduled_works+0x9b1/0x17a0 kernel/workqueue.c:3319
 #1: ffffc90000117c60 (net_cleanup_work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3214 [inline]
 #1: ffffc90000117c60 (net_cleanup_work){+.+.}-{0:0}, at: process_scheduled_works+0x9ec/0x17a0 kernel/workqueue.c:3319
 #2: ffffffff8f2d54d0 (pernet_ops_rwsem){++++}-{4:4}, at: cleanup_net+0x145/0xbd0 net/core/net_namespace.c:608
1 lock held by khungtaskd/31:
 #0: ffffffff8df3b860 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #0: ffffffff8df3b860 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #0: ffffffff8df3b860 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6764
3 locks held by kworker/u8:4/62:
 #0: ffff88803005a948 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3213 [inline]
 #0: ffff88803005a948 ((wq_completion)ipv6_addrconf){+.+.}-{0:0}, at: process_scheduled_works+0x9b1/0x17a0 kernel/workqueue.c:3319
 #1: ffffc9000154fc60 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3214 [inline]
 #1: ffffc9000154fc60 ((work_completion)(&(&ifa->dad_work)->work)){+.+.}-{0:0}, at: process_scheduled_works+0x9ec/0x17a0 kernel/workqueue.c:3319
 #2: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_net_lock include/linux/rtnetlink.h:130 [inline]
 #2: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: addrconf_dad_work+0x112/0x14b0 net/ipv6/addrconf.c:4195
3 locks held by kworker/u8:8/1156:
 #0: ffff88801a089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3213 [inline]
 #0: ffff88801a089148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_scheduled_works+0x9b1/0x17a0 kernel/workqueue.c:3319
 #1: ffffc90003f3fc60 ((linkwatch_work).work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3214 [inline]
 #1: ffffc90003f3fc60 ((linkwatch_work).work){+.+.}-{0:0}, at: process_scheduled_works+0x9ec/0x17a0 kernel/workqueue.c:3319
 #2: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: linkwatch_event+0xe/0x60 net/core/link_watch.c:303
2 locks held by getty/5576:
 #0: ffff88803068f0a0 (&tty->ldisc_sem){++++}-{0:0}, at: tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:243
 #1: ffffc90002fee2f0 (&ldata->atomic_read_lock){+.+.}-{4:4}, at: n_tty_read+0x43e/0x1400 drivers/tty/n_tty.c:2222
1 lock held by udevd/5864:
2 locks held by udevd/5888:
1 lock held by syz-executor/18951:
 #0: ffffffff8df41338 (rcu_state.exp_mutex){+.+.}-{4:4}, at: exp_funnel_lock kernel/rcu/tree_exp.h:336 [inline]
 #0: ffffffff8df41338 (rcu_state.exp_mutex){+.+.}-{4:4}, at: synchronize_rcu_expedited+0x3b7/0x730 kernel/rcu/tree_exp.h:998
3 locks held by syz-executor/19370:
 #0: ffffffff8ea7bd60 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
 #0: ffffffff8ea7bd60 (&ops->srcu#2){.+.+}-{0:0}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
 #0: ffffffff8ea7bd60 (&ops->srcu#2){.+.+}-{0:0}, at: rtnl_link_ops_get+0x23/0x250 net/core/rtnetlink.c:570
 #1: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
 #1: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock net/core/rtnetlink.c:341 [inline]
 #1: ffffffff8f2e2008 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x8db/0x1c70 net/core/rtnetlink.c:4064
 #2: ffffffff8df41338 (rcu_state.exp_mutex){+.+.}-{4:4}, at: exp_funnel_lock kernel/rcu/tree_exp.h:304 [inline]
 #2: ffffffff8df41338 (rcu_state.exp_mutex){+.+.}-{4:4}, at: synchronize_rcu_expedited+0x2f4/0x730 kernel/rcu/tree_exp.h:998

=============================================

NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 31 Comm: khungtaskd Not tainted 6.15.0-rc4-syzkaller-00051-g7a13c14ee59d #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/19/2025
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 nmi_cpu_backtrace+0x39e/0x3d0 lib/nmi_backtrace.c:113
 nmi_trigger_cpumask_backtrace+0x17a/0x300 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:158 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:274 [inline]
 watchdog+0xfee/0x1030 kernel/hung_task.c:437
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 5960 Comm: udevd Not tainted 6.15.0-rc4-syzkaller-00051-g7a13c14ee59d #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/19/2025
RIP: 0010:memset_orig+0x46/0xb0 arch/x86/lib/memset_64.S:73
Code: 75 74 48 89 d1 48 c1 e9 06 74 39 66 0f 1f 84 00 00 00 00 00 48 ff c9 48 89 07 48 89 47 08 48 89 47 10 48 89 47 18 48 89 47 20 <48> 89 47 28 48 89 47 30 48 89 47 38 48 8d 7f 40 75 d8 0f 1f 84 00
RSP: 0018:ffffc90003eef9c0 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888030be4000 RCX: 0000000000000037
RDX: 0000000000001000 RSI: 0000000000000000 RDI: ffff888030be4200
RBP: 0000000000000c40 R08: ffffffff8f7daa77 R09: 0000000000000000
R10: ffff888030be4000 R11: fffffbfff1efb54f R12: ffff88801a042140
R13: ffff888030be4000 R14: 0000000000000000 R15: 0000000000001000
FS:  00007ff5bdb62c80(0000) GS:ffff888126200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000564955db1000 CR3: 0000000030456000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 slab_post_alloc_hook mm/slub.c:4164 [inline]
 slab_alloc_node mm/slub.c:4210 [inline]
 __do_kmalloc_node mm/slub.c:4340 [inline]
 __kmalloc_noprof+0x248/0x4f0 mm/slub.c:4353
 kmalloc_noprof include/linux/slab.h:909 [inline]
 tomoyo_realpath_from_path+0xe3/0x5d0 security/tomoyo/realpath.c:251
 tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
 tomoyo_path_perm+0x213/0x4b0 security/tomoyo/file.c:822
 security_inode_getattr+0x12f/0x330 security/security.c:2377
 vfs_getattr fs/stat.c:256 [inline]
 vfs_fstat fs/stat.c:278 [inline]
 vfs_fstatat+0xad/0x160 fs/stat.c:370
 __do_sys_newfstatat fs/stat.c:536 [inline]
 __se_sys_newfstatat fs/stat.c:530 [inline]
 __x64_sys_newfstatat+0x11c/0x1a0 fs/stat.c:530
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff5bd7165f4
Code: 64 c7 00 09 00 00 00 83 c8 ff c3 48 89 f2 b9 00 01 00 00 48 89 fe bf 9c ff ff ff e9 00 00 00 00 41 89 ca b8 06 01 00 00 0f 05 <45> 31 c0 3d 00 f0 ff ff 76 10 48 8b 15 03 a8 0d 00 f7 d8 41 83 c8
RSP: 002b:00007ffccc212828 EFLAGS: 00000206 ORIG_RAX: 0000000000000106
RAX: ffffffffffffffda RBX: 00007ff5bd7ee460 RCX: 00007ff5bd7165f4
RDX: 00007ffccc212830 RSI: 00007ff5bd7b3130 RDI: 0000000000000009
RBP: 0000564955796100 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000001000 R11: 0000000000000206 R12: 0000000000000002
R13: 0000000000000002 R14: 0000564955796100 R15: 0000564920123ea6
 </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 syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

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.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[syzbot]

syzbot has bisected this issue to:

commit 1d0b929fc070b4115403a0a6206a0c6a62dd61f5
Author: David Howells <dhowells@redhat.com>
Date:   Mon Feb 24 09:52:58 2025 +0000

    afs: Change dynroot to create contents on demand

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1522020c580000
start commit:   7a13c14ee59d Merge tag 'for-6.15-rc4-tag' of git://git.ker..
git tree:       upstream
final oops:     https://syzkaller.appspot.com/x/report.txt?x=1722020c580000
console output: https://syzkaller.appspot.com/x/log.txt?x=1322020c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a42a9d552788177b
dashboard link: https://syzkaller.appspot.com/bug?extid=750f21d691e244b473b1
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13a101cc580000

Reported-by: syzbot+750f21d691e244b473b1@syzkaller.appspotmail.com
Fixes: 1d0b929fc070 ("afs: Change dynroot to create contents on demand")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+750f21d691e244b473b1@syzkaller.appspotmail.com
Tested-by: syzbot+750f21d691e244b473b1@syzkaller.appspotmail.com

Tested on:

commit:         8630c59e Merge tag 'kbuild-v6.16' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1799120c580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d9ebb51ccc2ec42f
dashboard link: https://syzkaller.appspot.com/bug?extid=750f21d691e244b473b1
compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10620a82580000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[David Howells]

Hi,

In this:

syz_mount_image$erofs(&(0x7f00000003c0), &(0x7f0000000880)='./file0\x00', 0x8000c6, &(0x7f0000000240)=ANY=[], 0x0, 0x17d, &(0x7f0000001ac0)="$eJzsmLFP+kAUx7/vyg/yMy6uLg4SxcHSFjUuxLA5mogaNwlUghYx0EGYdPH/cHZwdvOPMM7qYFwY3Uxqej3oQQR10MT4PsPj+7h313evyXcoGIb5szw+vNyvFe+EAWASaaTU/89GXCO0+tfb83Jraj1/OfeUv041robPIwBB8PnnJwDcFAz4Kg+Cwd1p9VuE6OstCCwovQOCqfQeBLaVdkHYVfpA042w3jT3a55rlhteJRRWGOwwOGHIDffXPSNUtP5IW2+1O4clz3Ob3yg+ml+3IJDX+tPfV282ljY/GwK20jkQNpVeRao3m2gk2v2nE/H5xg/fnwULFr9NxP4UXBDmNX9KaP6R9evH2Va7s1irl6pu1T1ynNyKtWRZy05WGlEUx/jff+lPE9r5/0bUJimJk5LvN+0o9nMniu85rpD+J5CZjfLQ+5Mju4nWSe0jqTLGmHKGYRiGYRiGYRiGYRiGYZgvMAOSX0EldIo4GcDZkNVvAQAA///an3MA")

how do I manually extract the erofs image source, if that is indeed what it
is?  The obvious thought is that it's base64, but '$' isn't a valid character
for that.

Further, though syz-execprog does manage to extract it, it doesn't seem to
contain what the test is expecting:

[727ms] exec opts: procid=3 threaded=1 cover=0 comps=0 dedup=1 signal=0 timeouts=50/5000/1 prog=0 filter=0
spawned worker pid 2
#0 [731ms] -> syz_mount_image$erofs(0x200003c0, 0x20000880, 0x8000c6, 0x20000240, 0x0, 0x17d, 0x20001ac0)
syz_mount_image: size=381 loop='/dev/loop3' dir='./file0' fs='erofs' flags=8388806 opts=''
#0 [771ms] <- syz_mount_image$erofs=0x3
#0 [771ms] -> mkdirat(0xffffffffffffff9c, 0x20000840, 0xa4)
#0 [772ms] <- mkdirat=0x0
#0 [772ms] -> mount$overlay(0x0, 0x0, 0x0, 0x0, 0x0)
#0 [772ms] <- mount$overlay=0xffffffffffffffff errno=14
#0 [772ms] -> chdir(0x20000140)
#0 [773ms] <- chdir=0x0
#0 [773ms] -> mount$afs(0x0, 0x200001c0, 0x200002c0, 0x0, 0x20000580)
#0 [773ms] <- mount$afs=0xffffffffffffffff errno=2
#0 [774ms] -> chdir(0x200000c0)
#0 [775ms] <- chdir=0xffffffffffffffff errno=2
#0 [775ms] -> renameat2(0xffffffffffffff9c, 0x20000480, 0xffffffffffffff9c, 0x20000000, 0x2)
#0 [776ms] <- renameat2=0xffffffffffffffff errno=2 fault=0
2025/07/21 14:21:05 result: hanged=false err=<nil>

Here's an excerpt of the strace over the relevant thread region with the
write(stderr) syscalls filtered out:

memfd_create("syzkaller", 0)            = 3
mmap(NULL, 138412032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdf4200000
write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
munmap(0x7fbdf4200000, 8192)            = 0
openat(AT_FDCWD, "/dev/loop6", O_RDWR)  = 4
ioctl(4, LOOP_SET_FD, 3)                = 0
close(3)                                = 0
mkdirat(AT_FDCWD, "./file0", 0777)      = 0
mount("/dev/loop6", "./file0", "erofs", MS_NOSUID|MS_NODEV|MS_MANDLOCK|MS_DIRSYNC|MS_I_VERSION,
 "") = 0
openat(AT_FDCWD, "./file0", O_RDONLY|O_DIRECTORY) = 3
ioctl(4, LOOP_CLR_FD)                   = 0
close(4)                                = 0
mkdirat(AT_FDCWD, "./bus", 0244)        = 0
mount(NULL, NULL, NULL, 0, NULL)        = -1 EFAULT (Bad address)
chdir("./bus")                          = 0
mount(NULL, "./file0", "afs", 0, "dyn") = -1 ENOENT (No such file or directory)
chdir("./file0")                        = -1 ENOENT (No such file or directory)
renameat2(AT_FDCWD, "./file1", AT_FDCWD, "./file0", RENAME_EXCHANGE) = -1 ENOENT (No such file or directory)


Can you see if this can be reproduced by installing kafs-client and doing:

	systemctl start afs.mount
	cd /afs
	mv --exchange ./file0 ./file1

though possibly this needs running in its own network namespace.

I can't get syz-execprog to actually run the test properly, it would seem.  I
suspect something it missing from my kernel, but I'm not sure what.

David

Re: [syzbot] [afs?] INFO: task hung in afs_cell_purge (2)

[Aleksandr Nogikh]

Hi David,

On Mon, Jul 21, 2025 at 4:02 PM 'David Howells' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
> Hi,
>
> In this:
>
> syz_mount_image$erofs(&(0x7f00000003c0), &(0x7f0000000880)='./file0\x00', 0x8000c6, &(0x7f0000000240)=ANY=[], 0x0, 0x17d, &(0x7f0000001ac0)="$eJzsmLFP+kAUx7/vyg/yMy6uLg4SxcHSFjUuxLA5mogaNwlUghYx0EGYdPH/cHZwdvOPMM7qYFwY3Uxqej3oQQR10MT4PsPj+7h313evyXcoGIb5szw+vNyvFe+EAWASaaTU/89GXCO0+tfb83Jraj1/OfeUv041robPIwBB8PnnJwDcFAz4Kg+Cwd1p9VuE6OstCCwovQOCqfQeBLaVdkHYVfpA042w3jT3a55rlhteJRRWGOwwOGHIDffXPSNUtP5IW2+1O4clz3Ob3yg+ml+3IJDX+tPfV282ljY/GwK20jkQNpVeRao3m2gk2v2nE/H5xg/fnwULFr9NxP4UXBDmNX9KaP6R9evH2Va7s1irl6pu1T1ynNyKtWRZy05WGlEUx/jff+lPE9r5/0bUJimJk5LvN+0o9nMniu85rpD+J5CZjfLQ+5Mju4nWSe0jqTLGmHKGYRiGYRiGYRiGYRiGYZgvMAOSX0EldIo4GcDZkNVvAQAA///an3MA")
>
> how do I manually extract the erofs image source, if that is indeed what it
> is?  The obvious thought is that it's base64, but '$' isn't a valid character
> for that.

It's a base64 representation of a gzipped disk image. Syzbot does
extract the full disk image and share it in its bug reports and on its
web dashboard. See these link:

mounted in repro:
https://storage.googleapis.com/syzbot-assets/9edd5a22bff1/mount_0.gz


>
> Further, though syz-execprog does manage to extract it, it doesn't seem to
> contain what the test is expecting:
>
> [727ms] exec opts: procid=3 threaded=1 cover=0 comps=0 dedup=1 signal=0 timeouts=50/5000/1 prog=0 filter=0
> spawned worker pid 2
> #0 [731ms] -> syz_mount_image$erofs(0x200003c0, 0x20000880, 0x8000c6, 0x20000240, 0x0, 0x17d, 0x20001ac0)
> syz_mount_image: size=381 loop='/dev/loop3' dir='./file0' fs='erofs' flags=8388806 opts=''
> #0 [771ms] <- syz_mount_image$erofs=0x3
> #0 [771ms] -> mkdirat(0xffffffffffffff9c, 0x20000840, 0xa4)
> #0 [772ms] <- mkdirat=0x0
> #0 [772ms] -> mount$overlay(0x0, 0x0, 0x0, 0x0, 0x0)
> #0 [772ms] <- mount$overlay=0xffffffffffffffff errno=14
> #0 [772ms] -> chdir(0x20000140)
> #0 [773ms] <- chdir=0x0
> #0 [773ms] -> mount$afs(0x0, 0x200001c0, 0x200002c0, 0x0, 0x20000580)
> #0 [773ms] <- mount$afs=0xffffffffffffffff errno=2
> #0 [774ms] -> chdir(0x200000c0)
> #0 [775ms] <- chdir=0xffffffffffffffff errno=2
> #0 [775ms] -> renameat2(0xffffffffffffff9c, 0x20000480, 0xffffffffffffff9c, 0x20000000, 0x2)
> #0 [776ms] <- renameat2=0xffffffffffffffff errno=2 fault=0
> 2025/07/21 14:21:05 result: hanged=false err=<nil>
>
> Here's an excerpt of the strace over the relevant thread region with the
> write(stderr) syscalls filtered out:
>
> memfd_create("syzkaller", 0)            = 3
> mmap(NULL, 138412032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdf4200000
> write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192
> munmap(0x7fbdf4200000, 8192)            = 0
> openat(AT_FDCWD, "/dev/loop6", O_RDWR)  = 4
> ioctl(4, LOOP_SET_FD, 3)                = 0
> close(3)                                = 0
> mkdirat(AT_FDCWD, "./file0", 0777)      = 0
> mount("/dev/loop6", "./file0", "erofs", MS_NOSUID|MS_NODEV|MS_MANDLOCK|MS_DIRSYNC|MS_I_VERSION,
>  "") = 0
> openat(AT_FDCWD, "./file0", O_RDONLY|O_DIRECTORY) = 3
> ioctl(4, LOOP_CLR_FD)                   = 0
> close(4)                                = 0
> mkdirat(AT_FDCWD, "./bus", 0244)        = 0
> mount(NULL, NULL, NULL, 0, NULL)        = -1 EFAULT (Bad address)
> chdir("./bus")                          = 0
> mount(NULL, "./file0", "afs", 0, "dyn") = -1 ENOENT (No such file or directory)
> chdir("./file0")                        = -1 ENOENT (No such file or directory)
> renameat2(AT_FDCWD, "./file1", AT_FDCWD, "./file0", RENAME_EXCHANGE) = -1 ENOENT (No such file or directory)
>
>
> Can you see if this can be reproduced by installing kafs-client and doing:
>
>         systemctl start afs.mount
>         cd /afs
>         mv --exchange ./file0 ./file1
>
> though possibly this needs running in its own network namespace.
>
> I can't get syz-execprog to actually run the test properly, it would seem.  I
> suspect something it missing from my kernel, but I'm not sure what.
>
> David
>

-- 
Aleksandr