* [syzbot] [lsm?] general protection fault in hook_inode_free_security
@ 2024-05-08 19:32 syzbot
2024-05-10 0:01 ` Paul Moore
0 siblings, 1 reply; 5+ messages in thread
From: syzbot @ 2024-05-08 19:32 UTC (permalink / raw)
To: jmorris, linux-kernel, linux-security-module, mic, paul, serge,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: dccb07f2914c Merge tag 'for-6.9-rc7-tag' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14a46760980000
kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43
dashboard link: https://syzkaller.appspot.com/bug?extid=5446fbf332b0602ede0b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/39d66018d8ad/disk-dccb07f2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c160b651d1bc/vmlinux-dccb07f2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3662a33ac713/bzImage-dccb07f2.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com
general protection fault, probably for non-canonical address 0xdffffc018f62f515: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: probably user-memory-access in range [0x0000000c7b17a8a8-0x0000000c7b17a8af]
CPU: 1 PID: 5102 Comm: syz-executor.1 Not tainted 6.9.0-rc7-syzkaller-00012-gdccb07f2914c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f43c42de000 CR3: 00000000635f8000 CR4: 0000000000350ef0
Call Trace:
<TASK>
security_inode_free+0x4a/0xd0 security/security.c:1613
__destroy_inode+0x2d9/0x650 fs/inode.c:286
destroy_inode fs/inode.c:309 [inline]
evict+0x521/0x630 fs/inode.c:682
dispose_list fs/inode.c:700 [inline]
evict_inodes+0x5f9/0x690 fs/inode.c:750
generic_shutdown_super+0x9d/0x2d0 fs/super.c:626
kill_block_super+0x44/0x90 fs/super.c:1675
deactivate_locked_super+0xc6/0x130 fs/super.c:472
cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
task_work_run+0x251/0x310 kernel/task_work.c:180
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0xa1b/0x27e0 kernel/exit.c:878
do_group_exit+0x207/0x2c0 kernel/exit.c:1027
__do_sys_exit_group kernel/exit.c:1038 [inline]
__se_sys_exit_group kernel/exit.c:1036 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f731567dd69
Code: Unable to access opcode bytes at 0x7f731567dd3f.
RSP: 002b:00007fff4f0804d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f73156c93a3 RCX: 00007f731567dd69
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000002 R08: 00007fff4f07e277 R09: 00007fff4f081790
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff4f081790
R13: 00007f73156c937e R14: 00000000000154d0 R15: 000000000000001e
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555587f03978 CR3: 0000000049876000 CR4: 0000000000350ef0
----------------
Code disassembly (best guess):
0: 8a fd mov %ch,%bh
2: 48 8b 1b mov (%rbx),%rbx
5: 48 c7 c0 c4 4e d5 8d mov $0xffffffff8dd54ec4,%rax
c: 48 c1 e8 03 shr $0x3,%rax
10: 42 0f b6 04 30 movzbl (%rax,%r14,1),%eax
15: 84 c0 test %al,%al
17: 75 3e jne 0x57
19: 48 63 05 33 59 65 09 movslq 0x9655933(%rip),%rax # 0x9655953
20: 48 01 c3 add %rax,%rbx
23: 48 89 d8 mov %rbx,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 80 3c 30 00 cmpb $0x0,(%rax,%r14,1) <-- trapping instruction
2f: 74 08 je 0x39
31: 48 89 df mov %rbx,%rdi
34: e8 66 be 8a fd call 0xfd8abe9f
39: 48 83 3b 00 cmpq $0x0,(%rbx)
3d: 75 0d jne 0x4c
3f: e8 .byte 0xe8
---
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 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [lsm?] general protection fault in hook_inode_free_security
2024-05-08 19:32 [syzbot] [lsm?] general protection fault in hook_inode_free_security syzbot
@ 2024-05-10 0:01 ` Paul Moore
2024-05-15 15:12 ` Mickaël Salaün
0 siblings, 1 reply; 5+ messages in thread
From: Paul Moore @ 2024-05-10 0:01 UTC (permalink / raw)
To: syzbot
Cc: jmorris, linux-kernel, linux-security-module, mic, serge, syzkaller-bugs
On Wed, May 8, 2024 at 3:32 PM syzbot
<syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: dccb07f2914c Merge tag 'for-6.9-rc7-tag' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14a46760980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43
> dashboard link: https://syzkaller.appspot.com/bug?extid=5446fbf332b0602ede0b
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/39d66018d8ad/disk-dccb07f2.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/c160b651d1bc/vmlinux-dccb07f2.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3662a33ac713/bzImage-dccb07f2.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com
>
> general protection fault, probably for non-canonical address 0xdffffc018f62f515: 0000 [#1] PREEMPT SMP KASAN NOPTI
> KASAN: probably user-memory-access in range [0x0000000c7b17a8a8-0x0000000c7b17a8af]
> CPU: 1 PID: 5102 Comm: syz-executor.1 Not tainted 6.9.0-rc7-syzkaller-00012-gdccb07f2914c #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
> RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
Possibly a Landlock issue, Mickaël?
> Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
> RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
> RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
> RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
> R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
> R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
> FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f43c42de000 CR3: 00000000635f8000 CR4: 0000000000350ef0
> Call Trace:
> <TASK>
> security_inode_free+0x4a/0xd0 security/security.c:1613
> __destroy_inode+0x2d9/0x650 fs/inode.c:286
> destroy_inode fs/inode.c:309 [inline]
> evict+0x521/0x630 fs/inode.c:682
> dispose_list fs/inode.c:700 [inline]
> evict_inodes+0x5f9/0x690 fs/inode.c:750
> generic_shutdown_super+0x9d/0x2d0 fs/super.c:626
> kill_block_super+0x44/0x90 fs/super.c:1675
> deactivate_locked_super+0xc6/0x130 fs/super.c:472
> cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
> task_work_run+0x251/0x310 kernel/task_work.c:180
> exit_task_work include/linux/task_work.h:38 [inline]
> do_exit+0xa1b/0x27e0 kernel/exit.c:878
> do_group_exit+0x207/0x2c0 kernel/exit.c:1027
> __do_sys_exit_group kernel/exit.c:1038 [inline]
> __se_sys_exit_group kernel/exit.c:1036 [inline]
> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f731567dd69
> Code: Unable to access opcode bytes at 0x7f731567dd3f.
> RSP: 002b:00007fff4f0804d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 00007f73156c93a3 RCX: 00007f731567dd69
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000002 R08: 00007fff4f07e277 R09: 00007fff4f081790
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff4f081790
> R13: 00007f73156c937e R14: 00000000000154d0 R15: 000000000000001e
> </TASK>
> Modules linked in:
> ---[ end trace 0000000000000000 ]---
--
paul-moore.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [lsm?] general protection fault in hook_inode_free_security
2024-05-10 0:01 ` Paul Moore
@ 2024-05-15 15:12 ` Mickaël Salaün
2024-05-16 7:31 ` Mickaël Salaün
0 siblings, 1 reply; 5+ messages in thread
From: Mickaël Salaün @ 2024-05-15 15:12 UTC (permalink / raw)
To: Paul Moore, Jann Horn
Cc: syzbot, jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs, linux-fsdevel, Casey Schaufler,
Christian Brauner
On Thu, May 09, 2024 at 08:01:49PM -0400, Paul Moore wrote:
> On Wed, May 8, 2024 at 3:32 PM syzbot
> <syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: dccb07f2914c Merge tag 'for-6.9-rc7-tag' of git://git.kern..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14a46760980000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5446fbf332b0602ede0b
> > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/39d66018d8ad/disk-dccb07f2.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/c160b651d1bc/vmlinux-dccb07f2.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/3662a33ac713/bzImage-dccb07f2.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com
> >
> > general protection fault, probably for non-canonical address 0xdffffc018f62f515: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > KASAN: probably user-memory-access in range [0x0000000c7b17a8a8-0x0000000c7b17a8af]
> > CPU: 1 PID: 5102 Comm: syz-executor.1 Not tainted 6.9.0-rc7-syzkaller-00012-gdccb07f2914c #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
> > RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
>
> Possibly a Landlock issue, Mickaël?
It looks like security_inode_free() is called two times on the same
inode. This could happen if an inode labeled by Landlock is put
concurrently with release_inode() for a closed ruleset or with
hook_sb_delete(). I didn't find any race condition that could lead to
two calls to iput() though. Could WRITE_ONCE(object->underobj, NULL)
change anything even if object->lock is locked?
A bit unrelated but looking at the SELinux code, I see that selinux_inode()
checks `!inode->i_security`. In which case could this happen?
>
> > Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
> > RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
> > RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
> > RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
> > RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
> > R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
> > R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
> > FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f43c42de000 CR3: 00000000635f8000 CR4: 0000000000350ef0
> > Call Trace:
> > <TASK>
> > security_inode_free+0x4a/0xd0 security/security.c:1613
> > __destroy_inode+0x2d9/0x650 fs/inode.c:286
> > destroy_inode fs/inode.c:309 [inline]
> > evict+0x521/0x630 fs/inode.c:682
> > dispose_list fs/inode.c:700 [inline]
> > evict_inodes+0x5f9/0x690 fs/inode.c:750
> > generic_shutdown_super+0x9d/0x2d0 fs/super.c:626
> > kill_block_super+0x44/0x90 fs/super.c:1675
> > deactivate_locked_super+0xc6/0x130 fs/super.c:472
> > cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
> > task_work_run+0x251/0x310 kernel/task_work.c:180
> > exit_task_work include/linux/task_work.h:38 [inline]
> > do_exit+0xa1b/0x27e0 kernel/exit.c:878
> > do_group_exit+0x207/0x2c0 kernel/exit.c:1027
> > __do_sys_exit_group kernel/exit.c:1038 [inline]
> > __se_sys_exit_group kernel/exit.c:1036 [inline]
> > __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > RIP: 0033:0x7f731567dd69
> > Code: Unable to access opcode bytes at 0x7f731567dd3f.
> > RSP: 002b:00007fff4f0804d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> > RAX: ffffffffffffffda RBX: 00007f73156c93a3 RCX: 00007f731567dd69
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: 0000000000000002 R08: 00007fff4f07e277 R09: 00007fff4f081790
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff4f081790
> > R13: 00007f73156c937e R14: 00000000000154d0 R15: 000000000000001e
> > </TASK>
> > Modules linked in:
> > ---[ end trace 0000000000000000 ]---
>
> --
> paul-moore.com
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [lsm?] general protection fault in hook_inode_free_security
2024-05-15 15:12 ` Mickaël Salaün
@ 2024-05-16 7:31 ` Mickaël Salaün
2024-05-16 13:07 ` Mathieu Desnoyers
0 siblings, 1 reply; 5+ messages in thread
From: Mickaël Salaün @ 2024-05-16 7:31 UTC (permalink / raw)
To: Paul Moore, Jann Horn, Mathieu Desnoyers, Paul E. McKenney
Cc: syzbot, jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs, linux-fsdevel, Casey Schaufler,
Christian Brauner
Adding membarrier experts.
On Wed, May 15, 2024 at 05:12:58PM +0200, Mickaël Salaün wrote:
> On Thu, May 09, 2024 at 08:01:49PM -0400, Paul Moore wrote:
> > On Wed, May 8, 2024 at 3:32 PM syzbot
> > <syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: dccb07f2914c Merge tag 'for-6.9-rc7-tag' of git://git.kern..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14a46760980000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=5446fbf332b0602ede0b
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/39d66018d8ad/disk-dccb07f2.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/c160b651d1bc/vmlinux-dccb07f2.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/3662a33ac713/bzImage-dccb07f2.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com
> > >
> > > general protection fault, probably for non-canonical address 0xdffffc018f62f515: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > KASAN: probably user-memory-access in range [0x0000000c7b17a8a8-0x0000000c7b17a8af]
> > > CPU: 1 PID: 5102 Comm: syz-executor.1 Not tainted 6.9.0-rc7-syzkaller-00012-gdccb07f2914c #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
> > > RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
> >
> > Possibly a Landlock issue, Mickaël?
>
> It looks like security_inode_free() is called two times on the same
> inode. This could happen if an inode labeled by Landlock is put
> concurrently with release_inode() for a closed ruleset or with
> hook_sb_delete(). I didn't find any race condition that could lead to
> two calls to iput() though. Could WRITE_ONCE(object->underobj, NULL)
> change anything even if object->lock is locked?
>
> A bit unrelated but looking at the SELinux code, I see that selinux_inode()
> checks `!inode->i_security`. In which case could this happen?
>
> >
> > > Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
> > > RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
> > > RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
> > > RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
> > > RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
> > > R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
> > > R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
> > > FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00007f43c42de000 CR3: 00000000635f8000 CR4: 0000000000350ef0
> > > Call Trace:
> > > <TASK>
> > > security_inode_free+0x4a/0xd0 security/security.c:1613
> > > __destroy_inode+0x2d9/0x650 fs/inode.c:286
> > > destroy_inode fs/inode.c:309 [inline]
> > > evict+0x521/0x630 fs/inode.c:682
> > > dispose_list fs/inode.c:700 [inline]
> > > evict_inodes+0x5f9/0x690 fs/inode.c:750
> > > generic_shutdown_super+0x9d/0x2d0 fs/super.c:626
> > > kill_block_super+0x44/0x90 fs/super.c:1675
> > > deactivate_locked_super+0xc6/0x130 fs/super.c:472
> > > cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
> > > task_work_run+0x251/0x310 kernel/task_work.c:180
> > > exit_task_work include/linux/task_work.h:38 [inline]
> > > do_exit+0xa1b/0x27e0 kernel/exit.c:878
> > > do_group_exit+0x207/0x2c0 kernel/exit.c:1027
> > > __do_sys_exit_group kernel/exit.c:1038 [inline]
> > > __se_sys_exit_group kernel/exit.c:1036 [inline]
> > > __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
> > > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > > do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
> > > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > > RIP: 0033:0x7f731567dd69
> > > Code: Unable to access opcode bytes at 0x7f731567dd3f.
> > > RSP: 002b:00007fff4f0804d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> > > RAX: ffffffffffffffda RBX: 00007f73156c93a3 RCX: 00007f731567dd69
> > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > > RBP: 0000000000000002 R08: 00007fff4f07e277 R09: 00007fff4f081790
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff4f081790
> > > R13: 00007f73156c937e R14: 00000000000154d0 R15: 000000000000001e
> > > </TASK>
> > > Modules linked in:
> > > ---[ end trace 0000000000000000 ]---
> >
> > --
> > paul-moore.com
> >
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [syzbot] [lsm?] general protection fault in hook_inode_free_security
2024-05-16 7:31 ` Mickaël Salaün
@ 2024-05-16 13:07 ` Mathieu Desnoyers
0 siblings, 0 replies; 5+ messages in thread
From: Mathieu Desnoyers @ 2024-05-16 13:07 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore, Jann Horn, Paul E. McKenney
Cc: syzbot, jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs, linux-fsdevel, Casey Schaufler,
Christian Brauner
On 2024-05-16 03:31, Mickaël Salaün wrote:
> Adding membarrier experts.
I do not see how this relates to the membarrier(2) system call.
Thanks,
Mathieu
>
> On Wed, May 15, 2024 at 05:12:58PM +0200, Mickaël Salaün wrote:
>> On Thu, May 09, 2024 at 08:01:49PM -0400, Paul Moore wrote:
>>> On Wed, May 8, 2024 at 3:32 PM syzbot
>>> <syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit: dccb07f2914c Merge tag 'for-6.9-rc7-tag' of git://git.kern..
>>>> git tree: upstream
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=14a46760980000
>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=6d14c12b661fb43
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=5446fbf332b0602ede0b
>>>> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>>>>
>>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>>
>>>> Downloadable assets:
>>>> disk image: https://storage.googleapis.com/syzbot-assets/39d66018d8ad/disk-dccb07f2.raw.xz
>>>> vmlinux: https://storage.googleapis.com/syzbot-assets/c160b651d1bc/vmlinux-dccb07f2.xz
>>>> kernel image: https://storage.googleapis.com/syzbot-assets/3662a33ac713/bzImage-dccb07f2.xz
>>>>
>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>> Reported-by: syzbot+5446fbf332b0602ede0b@syzkaller.appspotmail.com
>>>>
>>>> general protection fault, probably for non-canonical address 0xdffffc018f62f515: 0000 [#1] PREEMPT SMP KASAN NOPTI
>>>> KASAN: probably user-memory-access in range [0x0000000c7b17a8a8-0x0000000c7b17a8af]
>>>> CPU: 1 PID: 5102 Comm: syz-executor.1 Not tainted 6.9.0-rc7-syzkaller-00012-gdccb07f2914c #0
>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
>>>> RIP: 0010:hook_inode_free_security+0x5b/0xb0 security/landlock/fs.c:1047
>>>
>>> Possibly a Landlock issue, Mickaël?
>>
>> It looks like security_inode_free() is called two times on the same
>> inode. This could happen if an inode labeled by Landlock is put
>> concurrently with release_inode() for a closed ruleset or with
>> hook_sb_delete(). I didn't find any race condition that could lead to
>> two calls to iput() though. Could WRITE_ONCE(object->underobj, NULL)
>> change anything even if object->lock is locked?
>>
>> A bit unrelated but looking at the SELinux code, I see that selinux_inode()
>> checks `!inode->i_security`. In which case could this happen?
>>
>>>
>>>> Code: 8a fd 48 8b 1b 48 c7 c0 c4 4e d5 8d 48 c1 e8 03 42 0f b6 04 30 84 c0 75 3e 48 63 05 33 59 65 09 48 01 c3 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 df e8 66 be 8a fd 48 83 3b 00 75 0d e8
>>>> RSP: 0018:ffffc9000307f9a8 EFLAGS: 00010212
>>>> RAX: 000000018f62f515 RBX: 0000000c7b17a8a8 RCX: ffff888027668000
>>>> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff88805c0bb270
>>>> RBP: ffffffff8c01fb00 R08: ffffffff82132a15 R09: 1ffff1100b81765f
>>>> R10: dffffc0000000000 R11: ffffffff846ff540 R12: dffffc0000000000
>>>> R13: 1ffff1100b817683 R14: dffffc0000000000 R15: dffffc0000000000
>>>> FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00007f43c42de000 CR3: 00000000635f8000 CR4: 0000000000350ef0
>>>> Call Trace:
>>>> <TASK>
>>>> security_inode_free+0x4a/0xd0 security/security.c:1613
>>>> __destroy_inode+0x2d9/0x650 fs/inode.c:286
>>>> destroy_inode fs/inode.c:309 [inline]
>>>> evict+0x521/0x630 fs/inode.c:682
>>>> dispose_list fs/inode.c:700 [inline]
>>>> evict_inodes+0x5f9/0x690 fs/inode.c:750
>>>> generic_shutdown_super+0x9d/0x2d0 fs/super.c:626
>>>> kill_block_super+0x44/0x90 fs/super.c:1675
>>>> deactivate_locked_super+0xc6/0x130 fs/super.c:472
>>>> cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
>>>> task_work_run+0x251/0x310 kernel/task_work.c:180
>>>> exit_task_work include/linux/task_work.h:38 [inline]
>>>> do_exit+0xa1b/0x27e0 kernel/exit.c:878
>>>> do_group_exit+0x207/0x2c0 kernel/exit.c:1027
>>>> __do_sys_exit_group kernel/exit.c:1038 [inline]
>>>> __se_sys_exit_group kernel/exit.c:1036 [inline]
>>>> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
>>>> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>>> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>>>> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>> RIP: 0033:0x7f731567dd69
>>>> Code: Unable to access opcode bytes at 0x7f731567dd3f.
>>>> RSP: 002b:00007fff4f0804d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
>>>> RAX: ffffffffffffffda RBX: 00007f73156c93a3 RCX: 00007f731567dd69
>>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
>>>> RBP: 0000000000000002 R08: 00007fff4f07e277 R09: 00007fff4f081790
>>>> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff4f081790
>>>> R13: 00007f73156c937e R14: 00000000000154d0 R15: 000000000000001e
>>>> </TASK>
>>>> Modules linked in:
>>>> ---[ end trace 0000000000000000 ]---
>>>
>>> --
>>> paul-moore.com
>>>
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-05-16 13:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-08 19:32 [syzbot] [lsm?] general protection fault in hook_inode_free_security syzbot
2024-05-10 0:01 ` Paul Moore
2024-05-15 15:12 ` Mickaël Salaün
2024-05-16 7:31 ` Mickaël Salaün
2024-05-16 13:07 ` Mathieu Desnoyers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).