[syzbot] [v9fs?] general protection fault in p9_client_walk

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: bb2281fb05e5 Merge tag 'x86_microcode_for_v6.14_rc6' of gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=154078b7980000
kernel config: https://syzkaller.appspot.com/x/.config?x=bed8205d3b84ef81
dashboard link: https://syzkaller.appspot.com/bug?extid=5b667f9a1fee4ba3775a
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-bb2281fb.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2a0a6e98a402/vmlinux-bb2281fb.xz
kernel image: https://storage.googleapis.com/syzbot-assets/55357371f99f/bzImage-bb2281fb.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 UID: 0 PID: 21142 Comm: syz.4.3149 Not tainted 6.14.0-rc5-syzkaller-00023-gbb2281fb05e5 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165
Code: 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 dd 95 b2 f6 48 89 d8 31 f6 48 c1 e8 03 66 89 74 24 40 48 c7 44 24 50 00 00 00 00 <42> 80 3c 30 00 0f 85 3e 04 00 00 31 ff 89 ee 4c 8b 33 e8 af 90 b2
RSP: 0018:ffffc90006b77a90 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc9002bc05000
RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000007 R09: fffffffffffff000
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000
R13: 0000000000000000 R14: dffffc0000000000 R15: 1ffff92000d6ef54
FS: 0000000000000000(0000) GS:ffff88802b600000(0063) knlGS:00000000f5106b40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000630b2000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
clone_fid fs/9p/fid.h:23 [inline]
v9fs_fid_xattr_set+0x119/0x2d0 fs/9p/xattr.c:121
v9fs_set_acl+0xe6/0x150 fs/9p/acl.c:276
v9fs_set_create_acl+0x4b/0x70 fs/9p/acl.c:306
v9fs_vfs_mkdir_dotl+0x517/0x6e0 fs/9p/vfs_inode_dotl.c:411
vfs_mkdir+0x57d/0x860 fs/namei.c:4313
do_mkdirat+0x301/0x3a0 fs/namei.c:4336
__do_sys_mkdirat fs/namei.c:4351 [inline]
__se_sys_mkdirat fs/namei.c:4349 [inline]
__ia32_sys_mkdirat+0x82/0xb0 fs/namei.c:4349
do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
__do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:387
do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:412
entry_SYSENTER_compat_after_hwframe+0x84/0x8e
RIP: 0023:0xf7fe0579
Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00
RSP: 002b:00000000f510655c EFLAGS: 00000296 ORIG_RAX: 0000000000000128
RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 0000000080000140
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165
Code: 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 dd 95 b2 f6 48 89 d8 31 f6 48 c1 e8 03 66 89 74 24 40 48 c7 44 24 50 00 00 00 00 <42> 80 3c 30 00 0f 85 3e 04 00 00 31 ff 89 ee 4c 8b 33 e8 af 90 b2
RSP: 0018:ffffc90006b77a90 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc9002bc05000
RDX: 0000000000080000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000007 R09: fffffffffffff000
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000
R13: 0000000000000000 R14: dffffc0000000000 R15: 1ffff92000d6ef54
FS: 0000000000000000(0000) GS:ffff88802b600000(0063) knlGS:00000000f5106b40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 000055eba214e600 CR3: 00000000630b2000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 28 00 sub %al,(%rax)
2: 00 00 add %al,(%rax)
4: 48 89 84 24 88 00 00 mov %rax,0x88(%rsp)
b: 00
c: 31 c0 xor %eax,%eax
e: e8 dd 95 b2 f6 call 0xf6b295f0
13: 48 89 d8 mov %rbx,%rax
16: 31 f6 xor %esi,%esi
18: 48 c1 e8 03 shr $0x3,%rax
1c: 66 89 74 24 40 mov %si,0x40(%rsp)
21: 48 c7 44 24 50 00 00 movq $0x0,0x50(%rsp)
28: 00 00
* 2a: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping instruction
2f: 0f 85 3e 04 00 00 jne 0x473
35: 31 ff xor %edi,%edi
37: 89 ee mov %ebp,%esi
39: 4c 8b 33 mov (%rbx),%r14
3c: e8 .byte 0xe8
3d: af scas %es:(%rdi),%eax
3e: 90 nop
3f: b2 .byte 0xb2


---
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 syzk...@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 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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 0fed89a961ea Merge tag 'hyperv-fixes-signed-20250311' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=173fa654580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f71f17a9b92472b2

dashboard link: https://syzkaller.appspot.com/bug?extid=5b667f9a1fee4ba3775a
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=177b6874580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=138b17a8580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-0fed89a9.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/178c4c7fb0b4/vmlinux-0fed89a9.xz
kernel image: https://storage.googleapis.com/syzbot-assets/97ef169a8fde/bzImage-0fed89a9.xz

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

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]

CPU: 3 UID: 0 PID: 5936 Comm: syz-executor316 Not tainted 6.14.0-rc6-syzkaller-00016-g0fed89a961ea #0

Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165

Code: 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 3d 44 b0 f6 48 89 d8 31 f6 48 c1 e8 03 66 89 74 24 40 48 c7 44 24 50 00 00 00 00 <42> 80 3c 30 00 0f 85 3e 04 00 00 31 ff 89 ee 4c 8b 33 e8 0f 3f b0
RSP: 0018:ffffc9000380faa0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffff88802a9bc880 RSI: 0000000000000000 RDI: 0000000000000000

RBP: 0000000000000001 R08: 0000000000000007 R09: fffffffffffff000
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000

R13: 0000000000000000 R14: dffffc0000000000 R15: 1ffff92000701f56
FS: 000055558c345380(0000) GS:ffff88806a900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f412d1932a9 CR3: 000000002107c000 CR4: 0000000000352ef0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
clone_fid fs/9p/fid.h:23 [inline]
v9fs_fid_xattr_set+0x119/0x2d0 fs/9p/xattr.c:121
v9fs_set_acl+0xe6/0x150 fs/9p/acl.c:276
v9fs_set_create_acl+0x4b/0x70 fs/9p/acl.c:306
v9fs_vfs_mkdir_dotl+0x517/0x6e0 fs/9p/vfs_inode_dotl.c:411
vfs_mkdir+0x57d/0x860 fs/namei.c:4313
do_mkdirat+0x301/0x3a0 fs/namei.c:4336

__do_sys_mkdir fs/namei.c:4356 [inline]
__se_sys_mkdir fs/namei.c:4354 [inline]
__x64_sys_mkdir+0xef/0x140 fs/namei.c:4354
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fd26f335429
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff6d918e28 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00004000000000c0 RCX: 00007fd26f335429
RDX: 00007fd26f335429 RSI: 0000000000000040 RDI: 00004000000000c0
RBP: 0000000000000073 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007fff6d919008 R14: 0000000000000001 R15: 0000000000000001

</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165

Code: 28 00 00 00 48 89 84 24 88 00 00 00 31 c0 e8 3d 44 b0 f6 48 89 d8 31 f6 48 c1 e8 03 66 89 74 24 40 48 c7 44 24 50 00 00 00 00 <42> 80 3c 30 00 0f 85 3e 04 00 00 31 ff 89 ee 4c 8b 33 e8 0f 3f b0
RSP: 0018:ffffc9000380faa0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffff88802a9bc880 RSI: 0000000000000000 RDI: 0000000000000000

RBP: 0000000000000001 R08: 0000000000000007 R09: fffffffffffff000
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000

R13: 0000000000000000 R14: dffffc0000000000 R15: 1ffff92000701f56
FS: 000055558c345380(0000) GS:ffff88806a900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f412d1932a9 CR3: 000000002107c000 CR4: 0000000000352ef0

DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 28 00 sub %al,(%rax)
2: 00 00 add %al,(%rax)
4: 48 89 84 24 88 00 00 mov %rax,0x88(%rsp)
b: 00
c: 31 c0 xor %eax,%eax

e: e8 3d 44 b0 f6 call 0xf6b04450

13: 48 89 d8 mov %rbx,%rax
16: 31 f6 xor %esi,%esi
18: 48 c1 e8 03 shr $0x3,%rax
1c: 66 89 74 24 40 mov %si,0x40(%rsp)
21: 48 c7 44 24 50 00 00 movq $0x0,0x50(%rsp)
28: 00 00
* 2a: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping instruction
2f: 0f 85 3e 04 00 00 jne 0x473
35: 31 ff xor %edi,%edi
37: 89 ee mov %ebp,%esi
39: 4c 8b 33 mov (%rbx),%r14
3c: e8 .byte 0xe8

3d: 0f 3f (bad)
3f: b0 .byte 0xb0


---
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.

[Christian Schoenebeck]

Just had a glimpse on it so far. IIUIC the trigger is in
v9fs_vfs_mkdir_dotl() [fs/9p/vfs_inode_dotl.c:411] ?

// NULLs out fid (since dafbe6897)
v9fs_fid_add(dentry, &fid);
// expects fid being non-NULL
v9fs_set_create_acl(inode, fid, dacl, pacl);

/Christian

[asma...@codewreck.org]

Christian Schoenebeck wrote on Wed, Mar 12, 2025 at 10:36:15AM +0100:
> > RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165

> > clone_fid fs/9p/fid.h:23 [inline]
> > v9fs_fid_xattr_set+0x119/0x2d0 fs/9p/xattr.c:121
> > v9fs_set_acl+0xe6/0x150 fs/9p/acl.c:276
> > v9fs_set_create_acl+0x4b/0x70 fs/9p/acl.c:306
> > v9fs_vfs_mkdir_dotl+0x517/0x6e0 fs/9p/vfs_inode_dotl.c:411
> > vfs_mkdir+0x57d/0x860 fs/namei.c:4313
> > do_mkdirat+0x301/0x3a0 fs/namei.c:4336
> > __do_sys_mkdir fs/namei.c:4356 [inline]
> > __se_sys_mkdir fs/namei.c:4354 [inline]
> > __x64_sys_mkdir+0xef/0x140 fs/namei.c:4354
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Just had a glimpse on it so far. IIUIC the trigger is in
> v9fs_vfs_mkdir_dotl() [fs/9p/vfs_inode_dotl.c:411] ?
>
> // NULLs out fid (since dafbe6897)
> v9fs_fid_add(dentry, &fid);
> // expects fid being non-NULL
> v9fs_set_create_acl(inode, fid, dacl, pacl);

Sounds about right, inverting the two calls probably makes sense?

OTOH I don't get why all mkdirs don't hit that.. ah, it's only a problem
if the parent directory has some ACL and none of our tests hit that :/

Well, it shouldn't be too hard to trigger & fix anyway, since you've
done this much want to send the patch?

Thanks,
--
Dominique Martinet | Asmadeus

[Christian Schoenebeck]

On Wednesday, March 12, 2025 1:13:37 PM CET asma...@codewreck.org wrote:
> Christian Schoenebeck wrote on Wed, Mar 12, 2025 at 10:36:15AM +0100:
> > > RIP: 0010:p9_client_walk+0x9a/0x530 net/9p/client.c:1165
> > > clone_fid fs/9p/fid.h:23 [inline]
> > > v9fs_fid_xattr_set+0x119/0x2d0 fs/9p/xattr.c:121
> > > v9fs_set_acl+0xe6/0x150 fs/9p/acl.c:276
> > > v9fs_set_create_acl+0x4b/0x70 fs/9p/acl.c:306
> > > v9fs_vfs_mkdir_dotl+0x517/0x6e0 fs/9p/vfs_inode_dotl.c:411
> > > vfs_mkdir+0x57d/0x860 fs/namei.c:4313
> > > do_mkdirat+0x301/0x3a0 fs/namei.c:4336
> > > __do_sys_mkdir fs/namei.c:4356 [inline]
> > > __se_sys_mkdir fs/namei.c:4354 [inline]
> > > __x64_sys_mkdir+0xef/0x140 fs/namei.c:4354
> > > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > > do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
> > > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Just had a glimpse on it so far. IIUIC the trigger is in
> > v9fs_vfs_mkdir_dotl() [fs/9p/vfs_inode_dotl.c:411] ?
> >
> > // NULLs out fid (since dafbe6897)
> > v9fs_fid_add(dentry, &fid);
> > // expects fid being non-NULL
> > v9fs_set_create_acl(inode, fid, dacl, pacl);
>
> Sounds about right, inverting the two calls probably makes sense?

Yeah, that was also my first though. Just didn't have time yet to check
whether that dentry was needed somewhere downwards that v9fs_set_create_acl()
call stack.

> OTOH I don't get why all mkdirs don't hit that.. ah, it's only a problem
> if the parent directory has some ACL and none of our tests hit that :/

There are test cases now?

> Well, it shouldn't be too hard to trigger & fix anyway, since you've
> done this much want to send the patch?

If it is not super urgent then I'll schedule some cycles. Not worried if
anyone is faster of course.

/Christian

[asma...@codewreck.org]

Christian Schoenebeck wrote on Wed, Mar 12, 2025 at 03:25:27PM +0100:
> > OTOH I don't get why all mkdirs don't hit that.. ah, it's only a problem
> > if the parent directory has some ACL and none of our tests hit that :/
>
> There are test cases now?

What, you want a proper CI ?!
I'm still running semi-manually but I'm testing the bare minimum works
before sending Linus pull requets.. Which doesn't include ACLs...

But now I'm looking Eric published https://github.com/v9fs/test which
has some github actions, perhaps I can add my handful of test cases
there and try to run that instead, at which point we can consider
running more complete test suites like xfstests which do have some acl
checks.
I'm sure plenty of what we do isn't quite valid and would fail tests,
but at least it could check we're not hitting any null deref or similar
bug...

> > Well, it shouldn't be too hard to trigger & fix anyway, since you've
> > done this much want to send the patch?
>
> If it is not super urgent then I'll schedule some cycles. Not worried if
> anyone is faster of course.

Given it's been broken since 6.0 (2.5 years ago) I guess we don't have
anyone using ACLs (or at least not creating directories), so it's
probably not super urgent..

--
Dominique Martinet | Asmadeus