2023-07-05 12:22:57

by syzbot

[permalink] [raw]
Subject: [syzbot] [overlayfs?] general protection fault in d_path

Hello,

syzbot found the following issue on:

HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]

general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
get_fs_root_rcu fs/d_path.c:244 [inline]
d_path+0x2f0/0x6e0 fs/d_path.c:286
audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
dump_common_audit_data security/lsm_audit.c:224 [inline]
common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
smack_log+0x421/0x540 security/smack/smack_access.c:383
smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
security_inode_getattr+0xd3/0x120 security/security.c:2114
vfs_getattr+0x25/0x70 fs/stat.c:167
ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
__fput+0x36a/0x950 fs/file_table.c:378
task_work_run+0x24a/0x300 kernel/task_work.c:179
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x68f/0x2290 kernel/exit.c:874
do_group_exit+0x206/0x2c0 kernel/exit.c:1024
get_signal+0x1709/0x17e0 kernel/signal.c:2877
arch_do_signal_or_restart+0x91/0x670 arch/x86/kernel/signal.c:308
exit_to_user_mode_loop+0x6a/0x100 kernel/entry/common.c:168
exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
syscall_exit_to_user_mode+0x64/0x280 kernel/entry/common.c:297
do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f7f3ca8c389
Code: Unable to access opcode bytes at 0x7f7f3ca8c35f.
RSP: 002b:00007f7f3d741168 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
RAX: fffffffffffffffb RBX: 00007f7f3cbac050 RCX: 00007f7f3ca8c389
RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000020000180
RBP: 00007f7f3cad7493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff8432555f R14: 00007f7f3d741300 R15: 0000000000022000
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 85 75 18 test %esi,0x18(%rbp)
3: 00 00 add %al,(%rax)
5: 83 3d 15 c8 2c 0d 00 cmpl $0x0,0xd2cc815(%rip) # 0xd2cc821
c: 48 89 9c 24 10 01 00 mov %rbx,0x110(%rsp)
13: 00
14: 0f 84 f8 0f 00 00 je 0x1012
1a: 83 3d 5c de b3 0b 00 cmpl $0x0,0xbb3de5c(%rip) # 0xbb3de7d
21: 74 34 je 0x57
23: 48 89 d0 mov %rdx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 80 3c 00 00 cmpb $0x0,(%rax,%r8,1) <-- trapping instruction
2f: 74 1a je 0x4b
31: 48 89 d7 mov %rdx,%rdi
34: e8 b4 51 79 00 callq 0x7951ed
39: 48 rex.W
3a: 8b .byte 0x8b
3b: 94 xchg %eax,%esp
3c: 24 80 and $0x80,%al


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

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

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

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

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


2023-07-05 13:31:56

by Christian Brauner

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
> kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
> dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
>
> general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
> CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
> RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
> seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
> get_fs_root_rcu fs/d_path.c:244 [inline]
> d_path+0x2f0/0x6e0 fs/d_path.c:286
> audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
> dump_common_audit_data security/lsm_audit.c:224 [inline]
> common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> smack_log+0x421/0x540 security/smack/smack_access.c:383
> smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
> security_inode_getattr+0xd3/0x120 security/security.c:2114
> vfs_getattr+0x25/0x70 fs/stat.c:167
> ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203

Ugh, I think the root of this might all be the call back into
vfs_getattr() that happens on overlayfs:

__fput()
-> ima_file_free()
-> mutex_lock()
-> vfs_getattr_nosec()
-> i_op->getattr() == ovl_getattr()
-> vfs_getattr()
-> security_inode_getattr()
-> mutex_unlock()

So either overlayfs needs to call vfs_getattr_nosec() when the request
comes from vfs_getattr_nosec() or this needs to use
backing_file_real_path() to operate on the real underlying path.

Thoughts?

> __fput+0x36a/0x950 fs/file_table.c:378
> task_work_run+0x24a/0x300 kernel/task_work.c:179
> exit_task_work include/linux/task_work.h:38 [inline]
> do_exit+0x68f/0x2290 kernel/exit.c:874
> do_group_exit+0x206/0x2c0 kernel/exit.c:1024
> get_signal+0x1709/0x17e0 kernel/signal.c:2877
> arch_do_signal_or_restart+0x91/0x670 arch/x86/kernel/signal.c:308
> exit_to_user_mode_loop+0x6a/0x100 kernel/entry/common.c:168
> exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:204
> __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
> syscall_exit_to_user_mode+0x64/0x280 kernel/entry/common.c:297
> do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f7f3ca8c389
> Code: Unable to access opcode bytes at 0x7f7f3ca8c35f.
> RSP: 002b:00007f7f3d741168 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
> RAX: fffffffffffffffb RBX: 00007f7f3cbac050 RCX: 00007f7f3ca8c389
> RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000020000180
> RBP: 00007f7f3cad7493 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff8432555f R14: 00007f7f3d741300 R15: 0000000000022000
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
> 0: 85 75 18 test %esi,0x18(%rbp)
> 3: 00 00 add %al,(%rax)
> 5: 83 3d 15 c8 2c 0d 00 cmpl $0x0,0xd2cc815(%rip) # 0xd2cc821
> c: 48 89 9c 24 10 01 00 mov %rbx,0x110(%rsp)
> 13: 00
> 14: 0f 84 f8 0f 00 00 je 0x1012
> 1a: 83 3d 5c de b3 0b 00 cmpl $0x0,0xbb3de5c(%rip) # 0xbb3de7d
> 21: 74 34 je 0x57
> 23: 48 89 d0 mov %rdx,%rax
> 26: 48 c1 e8 03 shr $0x3,%rax
> * 2a: 42 80 3c 00 00 cmpb $0x0,(%rax,%r8,1) <-- trapping instruction
> 2f: 74 1a je 0x4b
> 31: 48 89 d7 mov %rdx,%rdi
> 34: e8 b4 51 79 00 callq 0x7951ed
> 39: 48 rex.W
> 3a: 8b .byte 0x8b
> 3b: 94 xchg %eax,%esp
> 3c: 24 80 and $0x80,%al
>
>
> ---
> 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.
>
> If the bug is already fixed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to change bug's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the bug is a duplicate of another bug, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup

2023-07-05 13:53:00

by Amir Goldstein

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, Jul 5, 2023 at 4:06 PM Christian Brauner <[email protected]> wrote:
>
> On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> > compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: [email protected]
> >
> > general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
> > CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
> > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
> > seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
> > get_fs_root_rcu fs/d_path.c:244 [inline]
> > d_path+0x2f0/0x6e0 fs/d_path.c:286
> > audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
> > dump_common_audit_data security/lsm_audit.c:224 [inline]
> > common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> > smack_log+0x421/0x540 security/smack/smack_access.c:383
> > smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> > smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
> > security_inode_getattr+0xd3/0x120 security/security.c:2114
> > vfs_getattr+0x25/0x70 fs/stat.c:167
> > ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> > ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> > ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
>
> Ugh, I think the root of this might all be the call back into
> vfs_getattr() that happens on overlayfs:
>
> __fput()
> -> ima_file_free()
> -> mutex_lock()
> -> vfs_getattr_nosec()
> -> i_op->getattr() == ovl_getattr()
> -> vfs_getattr()
> -> security_inode_getattr()
> -> mutex_unlock()
>
> So either overlayfs needs to call vfs_getattr_nosec() when the request
> comes from vfs_getattr_nosec() or this needs to use
> backing_file_real_path() to operate on the real underlying path.
>
> Thoughts?

The latter.

IMA code cannot operate on a mixture of real inode (file_inode())
real dentry (file_dentry()) and ovl path, especially for reading
stat.change_cookie which is not really well defined in ovl.

At least those direct f_path references need to be fixed:

security/integrity/ima/ima_main.c:
vfs_getattr_nosec(&file->f_path, &stat,
security/integrity/ima/ima_api.c: result =
vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
security/integrity/ima/ima_crypto.c: f =
dentry_open(&file->f_path, flags, file->f_cred);

and then all the places that format full path for audit logs:
security/integrity/ima/ima_main.c: *pathname =
ima_d_path(&file->f_path, pathbuf, filename);

Need to decide if it is prefered to log the full ovl path or the
relative real path (relative to the private mount clone of the ovl layer).

Thanks,
Amir.

2023-07-05 13:54:41

by Jeff Layton

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, 2023-07-05 at 15:05 +0200, Christian Brauner wrote:
> On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> > compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: [email protected]
> >
> > general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
> > CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
> > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
> > seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
> > get_fs_root_rcu fs/d_path.c:244 [inline]
> > d_path+0x2f0/0x6e0 fs/d_path.c:286
> > audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
> > dump_common_audit_data security/lsm_audit.c:224 [inline]
> > common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> > smack_log+0x421/0x540 security/smack/smack_access.c:383
> > smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> > smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
> > security_inode_getattr+0xd3/0x120 security/security.c:2114
> > vfs_getattr+0x25/0x70 fs/stat.c:167
> > ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> > ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> > ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
>
> Ugh, I think the root of this might all be the call back into
> vfs_getattr() that happens on overlayfs:
>
> __fput()
> -> ima_file_free()
> -> mutex_lock()
> -> vfs_getattr_nosec()
> -> i_op->getattr() == ovl_getattr()
> -> vfs_getattr()
> -> security_inode_getattr()
> -> mutex_unlock()
>
> So either overlayfs needs to call vfs_getattr_nosec() when the request
> comes from vfs_getattr_nosec() or this needs to use
> backing_file_real_path() to operate on the real underlying path.
>
> Thoughts?
>

When you say "this needs to use backing_file_real_path()", what do you
mean by "this"? IMA?

That said, passing some sort of NOSEC flag to vfs_getattr that
designates the call as kernel-internal seems like the more correct thing
to do here, and might be useful in other weird stacking cases like this.

> > __fput+0x36a/0x950 fs/file_table.c:378
> > task_work_run+0x24a/0x300 kernel/task_work.c:179
> > exit_task_work include/linux/task_work.h:38 [inline]
> > do_exit+0x68f/0x2290 kernel/exit.c:874
> > do_group_exit+0x206/0x2c0 kernel/exit.c:1024
> > get_signal+0x1709/0x17e0 kernel/signal.c:2877
> > arch_do_signal_or_restart+0x91/0x670 arch/x86/kernel/signal.c:308
> > exit_to_user_mode_loop+0x6a/0x100 kernel/entry/common.c:168
> > exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:204
> > __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
> > syscall_exit_to_user_mode+0x64/0x280 kernel/entry/common.c:297
> > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
> > entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > RIP: 0033:0x7f7f3ca8c389
> > Code: Unable to access opcode bytes at 0x7f7f3ca8c35f.
> > RSP: 002b:00007f7f3d741168 EFLAGS: 00000246 ORIG_RAX: 0000000000000052
> > RAX: fffffffffffffffb RBX: 00007f7f3cbac050 RCX: 00007f7f3ca8c389
> > RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000020000180
> > RBP: 00007f7f3cad7493 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007fff8432555f R14: 00007f7f3d741300 R15: 0000000000022000
> > </TASK>
> > Modules linked in:
> > ---[ end trace 0000000000000000 ]---
> > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > ----------------
> > Code disassembly (best guess):
> > 0: 85 75 18 test %esi,0x18(%rbp)
> > 3: 00 00 add %al,(%rax)
> > 5: 83 3d 15 c8 2c 0d 00 cmpl $0x0,0xd2cc815(%rip) # 0xd2cc821
> > c: 48 89 9c 24 10 01 00 mov %rbx,0x110(%rsp)
> > 13: 00
> > 14: 0f 84 f8 0f 00 00 je 0x1012
> > 1a: 83 3d 5c de b3 0b 00 cmpl $0x0,0xbb3de5c(%rip) # 0xbb3de7d
> > 21: 74 34 je 0x57
> > 23: 48 89 d0 mov %rdx,%rax
> > 26: 48 c1 e8 03 shr $0x3,%rax
> > * 2a: 42 80 3c 00 00 cmpb $0x0,(%rax,%r8,1) <-- trapping instruction
> > 2f: 74 1a je 0x4b
> > 31: 48 89 d7 mov %rdx,%rdi
> > 34: e8 b4 51 79 00 callq 0x7951ed
> > 39: 48 rex.W
> > 3a: 8b .byte 0x8b
> > 3b: 94 xchg %eax,%esp
> > 3c: 24 80 and $0x80,%al
> >
> >
> > ---
> > 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.
> >
> > If the bug is already fixed, let syzbot know by replying with:
> > #syz fix: exact-commit-title
> >
> > If you want to change bug's subsystems, reply with:
> > #syz set subsystems: new-subsystem
> > (See the list of subsystem names on the web dashboard)
> >
> > If the bug is a duplicate of another bug, reply with:
> > #syz dup: exact-subject-of-another-report
> >
> > If you want to undo deduplication, reply with:
> > #syz undup

--
Jeff Layton <[email protected]>

2023-07-05 14:16:55

by Amir Goldstein

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, Jul 5, 2023 at 4:41 PM Jeff Layton <[email protected]> wrote:
>
> On Wed, 2023-07-05 at 15:05 +0200, Christian Brauner wrote:
> > On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> > > compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: [email protected]
> > >
> > > general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
> > > KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
> > > CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
> > > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> > > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> > > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> > > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> > > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> > > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> > > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> > > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> > > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > Call Trace:
> > > <TASK>
> > > lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
> > > seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
> > > get_fs_root_rcu fs/d_path.c:244 [inline]
> > > d_path+0x2f0/0x6e0 fs/d_path.c:286
> > > audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
> > > dump_common_audit_data security/lsm_audit.c:224 [inline]
> > > common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> > > smack_log+0x421/0x540 security/smack/smack_access.c:383
> > > smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> > > smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
> > > security_inode_getattr+0xd3/0x120 security/security.c:2114
> > > vfs_getattr+0x25/0x70 fs/stat.c:167
> > > ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> > > ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> > > ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
> >
> > Ugh, I think the root of this might all be the call back into
> > vfs_getattr() that happens on overlayfs:
> >
> > __fput()
> > -> ima_file_free()
> > -> mutex_lock()
> > -> vfs_getattr_nosec()
> > -> i_op->getattr() == ovl_getattr()
> > -> vfs_getattr()
> > -> security_inode_getattr()
> > -> mutex_unlock()
> >
> > So either overlayfs needs to call vfs_getattr_nosec() when the request
> > comes from vfs_getattr_nosec() or this needs to use
> > backing_file_real_path() to operate on the real underlying path.
> >
> > Thoughts?
> >
>
> When you say "this needs to use backing_file_real_path()", what do you
> mean by "this"? IMA?
>
> That said, passing some sort of NOSEC flag to vfs_getattr that
> designates the call as kernel-internal seems like the more correct thing
> to do here, and might be useful in other weird stacking cases like this.
>

I don't think that NOSEC is the root cause.

If you ever noticed file_dentry() sprinkled through fs code,
it is only there because if that code were to call use helpers
that rely on file_inode() and d_inode(file->f_path.dentry) being
the same - bad things will happen and NOSEC will not cover
all those bad things.

IMA code also has file_dentry() sprinkled.
But it still accesses file->f_path in a few places and that
can result in bad things.

Thanks,
Amir.

2023-07-05 14:21:29

by Jeff Layton

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, 2023-07-05 at 16:54 +0300, Amir Goldstein wrote:
> On Wed, Jul 5, 2023 at 4:41 PM Jeff Layton <[email protected]> wrote:
> >
> > On Wed, 2023-07-05 at 15:05 +0200, Christian Brauner wrote:
> > > On Wed, Jul 05, 2023 at 05:00:45AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit: d528014517f2 Revert ".gitignore: ignore *.cover and *.mbx"
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14fad002a80000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1085b4238c9eb6ba
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> > > > compiler: Debian clang version 15.0.7, 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/fef94e788067/disk-d5280145.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/576412ea518b/vmlinux-d5280145.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/685a0e4be06b/bzImage-d5280145.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: [email protected]
> > > >
> > > > general protection fault, probably for non-canonical address 0xdffffc000000000a: 0000 [#1] PREEMPT SMP KASAN
> > > > KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
> > > > CPU: 1 PID: 10127 Comm: syz-executor.3 Not tainted 6.4.0-syzkaller-11478-gd528014517f2 #0
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
> > > > RIP: 0010:__lock_acquire+0x10d/0x7f70 kernel/locking/lockdep.c:5012
> > > > Code: 85 75 18 00 00 83 3d 15 c8 2c 0d 00 48 89 9c 24 10 01 00 00 0f 84 f8 0f 00 00 83 3d 5c de b3 0b 00 74 34 48 89 d0 48 c1 e8 03 <42> 80 3c 00 00 74 1a 48 89 d7 e8 b4 51 79 00 48 8b 94 24 80 00 00
> > > > RSP: 0018:ffffc900169be9e0 EFLAGS: 00010006
> > > > RAX: 000000000000000a RBX: 1ffff92002d37d60 RCX: 0000000000000002
> > > > RDX: 0000000000000050 RSI: 0000000000000000 RDI: 0000000000000050
> > > > RBP: ffffc900169beca8 R08: dffffc0000000000 R09: 0000000000000001
> > > > R10: dffffc0000000000 R11: fffffbfff1d2fe76 R12: 0000000000000000
> > > > R13: 0000000000000001 R14: 0000000000000002 R15: ffff88802091d940
> > > > FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > CR2: 00007fa22a3fe000 CR3: 000000004b5e1000 CR4: 00000000003506e0
> > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > > Call Trace:
> > > > <TASK>
> > > > lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
> > > > seqcount_lockdep_reader_access+0x139/0x220 include/linux/seqlock.h:102
> > > > get_fs_root_rcu fs/d_path.c:244 [inline]
> > > > d_path+0x2f0/0x6e0 fs/d_path.c:286
> > > > audit_log_d_path+0xd3/0x310 kernel/audit.c:2139
> > > > dump_common_audit_data security/lsm_audit.c:224 [inline]
> > > > common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> > > > smack_log+0x421/0x540 security/smack/smack_access.c:383
> > > > smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> > > > smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1202
> > > > security_inode_getattr+0xd3/0x120 security/security.c:2114
> > > > vfs_getattr+0x25/0x70 fs/stat.c:167
> > > > ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> > > > ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> > > > ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
> > >
> > > Ugh, I think the root of this might all be the call back into
> > > vfs_getattr() that happens on overlayfs:
> > >
> > > __fput()
> > > -> ima_file_free()
> > > -> mutex_lock()
> > > -> vfs_getattr_nosec()
> > > -> i_op->getattr() == ovl_getattr()
> > > -> vfs_getattr()
> > > -> security_inode_getattr()
> > > -> mutex_unlock()
> > >
> > > So either overlayfs needs to call vfs_getattr_nosec() when the request
> > > comes from vfs_getattr_nosec() or this needs to use
> > > backing_file_real_path() to operate on the real underlying path.
> > >
> > > Thoughts?
> > >
> >
> > When you say "this needs to use backing_file_real_path()", what do you
> > mean by "this"? IMA?
> >
> > That said, passing some sort of NOSEC flag to vfs_getattr that
> > designates the call as kernel-internal seems like the more correct thing
> > to do here, and might be useful in other weird stacking cases like this.
> >
>
> I don't think that NOSEC is the root cause.
>
> If you ever noticed file_dentry() sprinkled through fs code,
> it is only there because if that code were to call use helpers
> that rely on file_inode() and d_inode(file->f_path.dentry) being
> the same - bad things will happen and NOSEC will not cover
> all those bad things.
>
> IMA code also has file_dentry() sprinkled.
> But it still accesses file->f_path in a few places and that
> can result in bad things.
>

Ok, that makes sense, and is a lot less invasive than having to rework
vfs_getattr.
--
Jeff Layton <[email protected]>

2023-09-12 22:18:51

by syzbot

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

syzbot has found a reproducer for the following issue on:

HEAD commit: a747acc0b752 Merge tag 'linux-kselftest-next-6.6-rc2' of g..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=11c82308680000
kernel config: https://syzkaller.appspot.com/x/.config?x=df91a3034fe3f122
dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1671b694680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ec94d8680000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b28ecb88c714/disk-a747acc0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/03dd2cd5356f/vmlinux-a747acc0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/63365d9bf980/bzImage-a747acc0.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]

general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
CPU: 0 PID: 5030 Comm: syz-executor173 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
RIP: 0010:__seqprop_spinlock_sequence include/linux/seqlock.h:275 [inline]
RIP: 0010:get_fs_root_rcu fs/d_path.c:244 [inline]
RIP: 0010:d_path+0x2f0/0x6e0 fs/d_path.c:286
Code: 30 00 74 08 48 89 df e8 be 20 e1 ff 4c 8b 23 4d 8d 6c 24 48 49 81 c4 88 00 00 00 4c 89 eb 48 c1 eb 03 4c 89 ef e8 00 1e 00 00 <42> 0f b6 04 33 84 c0 0f 85 89 00 00 00 45 8b 7d 00 44 89 fe 83 e6
RSP: 0018:ffffc90003a7eee0 EFLAGS: 00010246
RAX: 7e73051ae5315e00 RBX: 0000000000000009 RCX: ffff88807da73b80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90003a7eff0 R08: ffffffff82068d08 R09: 1ffffffff1d34ccd
R10: dffffc0000000000 R11: fffffbfff1d34cce R12: 0000000000000088
R13: 0000000000000048 R14: dffffc0000000000 R15: ffff8880206d8000
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f351862ebb8 CR3: 00000000276a7000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
audit_log_d_path+0xd3/0x310 kernel/audit.c:2138
dump_common_audit_data security/lsm_audit.c:224 [inline]
common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
smack_log+0x421/0x540 security/smack/smack_access.c:383
smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1271
security_inode_getattr+0xd3/0x120 security/security.c:2153
vfs_getattr+0x2a/0x3a0 fs/stat.c:206
ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
__fput+0x36a/0x910 fs/file_table.c:378
task_work_run+0x24a/0x300 kernel/task_work.c:179
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x68f/0x2290 kernel/exit.c:874
do_group_exit+0x206/0x2c0 kernel/exit.c:1024
get_signal+0x175d/0x1840 kernel/signal.c:2892
arch_do_signal_or_restart+0x96/0x860 arch/x86/kernel/signal.c:309
exit_to_user_mode_loop+0x6a/0x100 kernel/entry/common.c:168
exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x64/0x280 kernel/entry/common.c:296
do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f35185d8529
Code: Unable to access opcode bytes at 0x7f35185d84ff.
RSP: 002b:00007f3518599218 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: 0000000000000001 RBX: 00007f3518662308 RCX: 00007f35185d8529
RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f351866230c
RBP: 00007f3518662300 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f351862f064
R13: 0031656c69662f2e R14: 6e6f3d7865646e69 R15: 0079616c7265766f
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__seqprop_spinlock_sequence include/linux/seqlock.h:275 [inline]
RIP: 0010:get_fs_root_rcu fs/d_path.c:244 [inline]
RIP: 0010:d_path+0x2f0/0x6e0 fs/d_path.c:286
Code: 30 00 74 08 48 89 df e8 be 20 e1 ff 4c 8b 23 4d 8d 6c 24 48 49 81 c4 88 00 00 00 4c 89 eb 48 c1 eb 03 4c 89 ef e8 00 1e 00 00 <42> 0f b6 04 33 84 c0 0f 85 89 00 00 00 45 8b 7d 00 44 89 fe 83 e6
RSP: 0018:ffffc90003a7eee0 EFLAGS: 00010246
RAX: 7e73051ae5315e00 RBX: 0000000000000009 RCX: ffff88807da73b80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc90003a7eff0 R08: ffffffff82068d08 R09: 1ffffffff1d34ccd
R10: dffffc0000000000 R11: fffffbfff1d34cce R12: 0000000000000088
R13: 0000000000000048 R14: dffffc0000000000 R15: ffff8880206d8000
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f351862ebb8 CR3: 000000007e769000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
0: 30 00 xor %al,(%rax)
2: 74 08 je 0xc
4: 48 89 df mov %rbx,%rdi
7: e8 be 20 e1 ff call 0xffe120ca
c: 4c 8b 23 mov (%rbx),%r12
f: 4d 8d 6c 24 48 lea 0x48(%r12),%r13
14: 49 81 c4 88 00 00 00 add $0x88,%r12
1b: 4c 89 eb mov %r13,%rbx
1e: 48 c1 eb 03 shr $0x3,%rbx
22: 4c 89 ef mov %r13,%rdi
25: e8 00 1e 00 00 call 0x1e2a
* 2a: 42 0f b6 04 33 movzbl (%rbx,%r14,1),%eax <-- trapping instruction
2f: 84 c0 test %al,%al
31: 0f 85 89 00 00 00 jne 0xc0
37: 45 8b 7d 00 mov 0x0(%r13),%r15d
3b: 44 89 fe mov %r15d,%esi
3e: 83 .byte 0x83
3f: e6 .byte 0xe6


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

2023-09-13 17:00:39

by Amir Goldstein

[permalink] [raw]
Subject: Re: [syzbot] [overlayfs?] general protection fault in d_path

On Wed, Sep 13, 2023 at 1:10 AM syzbot
<[email protected]> wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: a747acc0b752 Merge tag 'linux-kselftest-next-6.6-rc2' of g..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=11c82308680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df91a3034fe3f122
> dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1671b694680000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ec94d8680000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b28ecb88c714/disk-a747acc0.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/03dd2cd5356f/vmlinux-a747acc0.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/63365d9bf980/bzImage-a747acc0.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
>
> general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
> CPU: 0 PID: 5030 Comm: syz-executor173 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
> RIP: 0010:__seqprop_spinlock_sequence include/linux/seqlock.h:275 [inline]
> RIP: 0010:get_fs_root_rcu fs/d_path.c:244 [inline]
> RIP: 0010:d_path+0x2f0/0x6e0 fs/d_path.c:286
> Code: 30 00 74 08 48 89 df e8 be 20 e1 ff 4c 8b 23 4d 8d 6c 24 48 49 81 c4 88 00 00 00 4c 89 eb 48 c1 eb 03 4c 89 ef e8 00 1e 00 00 <42> 0f b6 04 33 84 c0 0f 85 89 00 00 00 45 8b 7d 00 44 89 fe 83 e6
> RSP: 0018:ffffc90003a7eee0 EFLAGS: 00010246
> RAX: 7e73051ae5315e00 RBX: 0000000000000009 RCX: ffff88807da73b80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffc90003a7eff0 R08: ffffffff82068d08 R09: 1ffffffff1d34ccd
> R10: dffffc0000000000 R11: fffffbfff1d34cce R12: 0000000000000088
> R13: 0000000000000048 R14: dffffc0000000000 R15: ffff8880206d8000
> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f351862ebb8 CR3: 00000000276a7000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> audit_log_d_path+0xd3/0x310 kernel/audit.c:2138
> dump_common_audit_data security/lsm_audit.c:224 [inline]
> common_lsm_audit+0x7cf/0x1a90 security/lsm_audit.c:458
> smack_log+0x421/0x540 security/smack/smack_access.c:383
> smk_tskacc+0x2ff/0x360 security/smack/smack_access.c:253
> smack_inode_getattr+0x203/0x270 security/smack/smack_lsm.c:1271
> security_inode_getattr+0xd3/0x120 security/security.c:2153
> vfs_getattr+0x2a/0x3a0 fs/stat.c:206
> ovl_getattr+0x1b1/0xf70 fs/overlayfs/inode.c:174
> ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
> ima_file_free+0x26e/0x4b0 security/integrity/ima/ima_main.c:203
> __fput+0x36a/0x910 fs/file_table.c:378
> task_work_run+0x24a/0x300 kernel/task_work.c:179
> exit_task_work include/linux/task_work.h:38 [inline]
> do_exit+0x68f/0x2290 kernel/exit.c:874
> do_group_exit+0x206/0x2c0 kernel/exit.c:1024
> get_signal+0x175d/0x1840 kernel/signal.c:2892
> arch_do_signal_or_restart+0x96/0x860 arch/x86/kernel/signal.c:309
> exit_to_user_mode_loop+0x6a/0x100 kernel/entry/common.c:168
> exit_to_user_mode_prepare+0xb1/0x140 kernel/entry/common.c:204
> __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
> syscall_exit_to_user_mode+0x64/0x280 kernel/entry/common.c:296
> do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f35185d8529
> Code: Unable to access opcode bytes at 0x7f35185d84ff.
> RSP: 002b:00007f3518599218 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
> RAX: 0000000000000001 RBX: 00007f3518662308 RCX: 00007f35185d8529
> RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 00007f351866230c
> RBP: 00007f3518662300 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f351862f064
> R13: 0031656c69662f2e R14: 6e6f3d7865646e69 R15: 0079616c7265766f
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:__seqprop_spinlock_sequence include/linux/seqlock.h:275 [inline]
> RIP: 0010:get_fs_root_rcu fs/d_path.c:244 [inline]
> RIP: 0010:d_path+0x2f0/0x6e0 fs/d_path.c:286
> Code: 30 00 74 08 48 89 df e8 be 20 e1 ff 4c 8b 23 4d 8d 6c 24 48 49 81 c4 88 00 00 00 4c 89 eb 48 c1 eb 03 4c 89 ef e8 00 1e 00 00 <42> 0f b6 04 33 84 c0 0f 85 89 00 00 00 45 8b 7d 00 44 89 fe 83 e6
> RSP: 0018:ffffc90003a7eee0 EFLAGS: 00010246
> RAX: 7e73051ae5315e00 RBX: 0000000000000009 RCX: ffff88807da73b80
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: ffffc90003a7eff0 R08: ffffffff82068d08 R09: 1ffffffff1d34ccd
> R10: dffffc0000000000 R11: fffffbfff1d34cce R12: 0000000000000088
> R13: 0000000000000048 R14: dffffc0000000000 R15: ffff8880206d8000
> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f351862ebb8 CR3: 000000007e769000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> ----------------
> Code disassembly (best guess):
> 0: 30 00 xor %al,(%rax)
> 2: 74 08 je 0xc
> 4: 48 89 df mov %rbx,%rdi
> 7: e8 be 20 e1 ff call 0xffe120ca
> c: 4c 8b 23 mov (%rbx),%r12
> f: 4d 8d 6c 24 48 lea 0x48(%r12),%r13
> 14: 49 81 c4 88 00 00 00 add $0x88,%r12
> 1b: 4c 89 eb mov %r13,%rbx
> 1e: 48 c1 eb 03 shr $0x3,%rbx
> 22: 4c 89 ef mov %r13,%rdi
> 25: e8 00 1e 00 00 call 0x1e2a
> * 2a: 42 0f b6 04 33 movzbl (%rbx,%r14,1),%eax <-- trapping instruction
> 2f: 84 c0 test %al,%al
> 31: 0f 85 89 00 00 00 jne 0xc0
> 37: 45 8b 7d 00 mov 0x0(%r13),%r15d
> 3b: 44 89 fe mov %r15d,%esi
> 3e: 83 .byte 0x83
> 3f: e6 .byte 0xe6
>
>
> ---
> 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.

#syz set subsystems: integrity, overlayfs

#syz test: https://github.com/amir73il/linux ima-ovl-fix

2023-09-18 00:05:52

by syzbot

[permalink] [raw]
Subject: Re: [syzbot] [integrity] [overlayfs] general protection fault in d_path

syzbot has bisected this issue to:

commit db1d1e8b9867aae5c3e61ad7859abfcc4a6fd6c7
Author: Jeff Layton <[email protected]>
Date: Mon Apr 17 16:55:51 2023 +0000

IMA: use vfs_getattr_nosec to get the i_version

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106f7e54680000
start commit: a747acc0b752 Merge tag 'linux-kselftest-next-6.6-rc2' of g..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=126f7e54680000
console output: https://syzkaller.appspot.com/x/log.txt?x=146f7e54680000
kernel config: https://syzkaller.appspot.com/x/.config?x=df91a3034fe3f122
dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1671b694680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ec94d8680000

Reported-by: [email protected]
Fixes: db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version")

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

2023-09-21 01:02:18

by Stefan Berger

[permalink] [raw]
Subject: Re: [syzbot] [integrity] [overlayfs] general protection fault in d_path


On 9/17/23 20:04, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit db1d1e8b9867aae5c3e61ad7859abfcc4a6fd6c7
> Author: Jeff Layton <[email protected]>
> Date: Mon Apr 17 16:55:51 2023 +0000
>
> IMA: use vfs_getattr_nosec to get the i_version
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106f7e54680000
> start commit: a747acc0b752 Merge tag 'linux-kselftest-next-6.6-rc2' of g..
> git tree: upstream
> final oops: https://syzkaller.appspot.com/x/report.txt?x=126f7e54680000
> console output: https://syzkaller.appspot.com/x/log.txt?x=146f7e54680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df91a3034fe3f122
> dashboard link: https://syzkaller.appspot.com/bug?extid=a67fc5321ffb4b311c98
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1671b694680000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ec94d8680000
>
> Reported-by: [email protected]
> Fixes: db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

The final oops shows this here:

BUG: kernel NULL pointer dereference, address: 0000000000000058
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 3192 Comm: syz-executor.0 Not tainted 6.4.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 08/04/2023
RIP: 0010:__lock_acquire+0x35/0x490 kernel/locking/lockdep.c:4946
Code: 83 ec 18 65 4c 8b 35 aa 60 f4 7e 83 3d b7 11 e4 02 00 0f 84 05 02
00 00 4c 89 cb 89 cd 41 89 d5 49 89 ff 83 fe 01 77 0c 89 f0 <49> 8b 44
c7 08 48 85 c0 75 1b 4c 89 ff 31 d2 45 89 c4 e8 74 f6 ff
RSP: 0018:ffffc90002edb840 EFLAGS: 00010097
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000050
RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff888102ea5340 R15: 0000000000000050
FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000058 CR3: 0000000003aa8000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 lock_acquire+0xd8/0x1f0 kernel/locking/lockdep.c:5691
 seqcount_lockdep_reader_access include/linux/seqlock.h:102 [inline]
 get_fs_root_rcu fs/d_path.c:243 [inline]
 d_path+0xd1/0x1f0 fs/d_path.c:285
 audit_log_d_path+0x65/0x130 kernel/audit.c:2139
 dump_common_audit_data security/lsm_audit.c:224 [inline]
 common_lsm_audit+0x3b3/0x840 security/lsm_audit.c:458
 smack_log+0xad/0x130 security/smack/smack_access.c:383
 smk_tskacc+0xb1/0xd0 security/smack/smack_access.c:253
 smack_inode_getattr+0x8a/0xb0 security/smack/smack_lsm.c:1187
 security_inode_getattr+0x32/0x50 security/security.c:2114
 vfs_getattr+0x1b/0x40 fs/stat.c:167
 ovl_getattr+0xa6/0x3e0 fs/overlayfs/inode.c:173
 ima_check_last_writer security/integrity/ima/ima_main.c:171 [inline]
 ima_file_free+0xbd/0x130 security/integrity/ima/ima_main.c:203
 __fput+0xc7/0x220 fs/file_table.c:315
 task_work_run+0x7d/0xa0 kernel/task_work.c:179
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0x2c7/0xa80 kernel/exit.c:871 <-----------------------
 do_group_exit+0x85/0xa0 kernel/exit.c:1021
 get_signal+0x73c/0x7f0 kernel/signal.c:2874
 arch_do_signal_or_restart+0x89/0x290 arch/x86/kernel/signal.c:306
 exit_to_user_mode_loop+0x61/0xb0 kernel/entry/common.c:168
 exit_to_user_mode_prepare+0x64/0xb0 kernel/entry/common.c:204
 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
 syscall_exit_to_user_mode+0x2b/0x1d0 kernel/entry/common.c:297
 do_syscall_64+0x4d/0x90 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd


do_exit has called exit_fs(tsk) [
https://elixir.bootlin.com/linux/v6.4-rc2/source/kernel/exit.c#L867 ]

exit_fs(tsk) has set tsk->fs = NULL [
https://elixir.bootlin.com/linux/v6.4-rc2/source/fs/fs_struct.c#L103 ]

I think this then bites in d_path() where it calls:

    get_fs_root_rcu(current->fs, &root);   [
https://elixir.bootlin.com/linux/v6.4-rc2/source/fs/d_path.c#L285 ]

current->fs is likely NULL here.

If this was correct it would have nothing to do with the actual patch,
though, but rather with the fact that smack logs on process termination.
I am not sure what the solution would be other than testing for
current->fs == NULL in d_path before using it and returning an error
that is not normally returned or trying to intercept this case in smack.

   Stefan