* [syzbot] [kernel?] WARNING in audit_log_start
@ 2024-08-26 8:29 syzbot
2024-09-02 8:37 ` Thomas Gleixner
0 siblings, 1 reply; 7+ messages in thread
From: syzbot @ 2024-08-26 8:29 UTC (permalink / raw)
To: linux-kernel, luto, peterz, syzkaller-bugs, tglx
Hello,
syzbot found the following issue on:
HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000
kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc
dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c
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/47820545bc51/disk-6a7917c8.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com
WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
Modules linked in:
CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff
RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246
RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000
RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728
RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364
R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000
R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c
FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
might_alloc include/linux/sched/mm.h:337 [inline]
slab_pre_alloc_hook mm/slub.c:3987 [inline]
slab_alloc_node mm/slub.c:4065 [inline]
kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
audit_buffer_alloc kernel/audit.c:1790 [inline]
audit_log_start+0x15e/0xa30 kernel/audit.c:1912
audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
seccomp_log kernel/seccomp.c:1016 [inline]
__seccomp_filter+0xb38/0x1fe0 kernel/seccomp.c:1305
syscall_trace_enter+0xa8/0x150 kernel/entry/common.c:52
syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline]
syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline]
do_syscall_64+0xcc/0x230 arch/x86/entry/common.c:79
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4cf4d157e9
Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 c7 c0 0f 00 00 00 0f 05 <0f> 1f 80 00 00 00 00 48 81 ec 48 01 00 00 49 89 d0 64 48 8b 04 25
RSP: 002b:00007f4cf5b69b40 EFLAGS: 00000206 ORIG_RAX: 000000000000000f
RAX: ffffffffffffffda RBX: 00007f4cf4f15f88 RCX: 00007f4cf4d157e9
RDX: 00007f4cf5b69b40 RSI: 00007f4cf5b69c70 RDI: 0000000000000021
RBP: 00007f4cf4f15f80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 00007f4cf4f15f8c
R13: 0000000000000000 R14: 00007fffe8828e10 R15: 00007fffe8828ef8
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want 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] 7+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-08-26 8:29 [syzbot] [kernel?] WARNING in audit_log_start syzbot
@ 2024-09-02 8:37 ` Thomas Gleixner
2024-09-03 19:22 ` Paul Moore
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Gleixner @ 2024-09-02 8:37 UTC (permalink / raw)
To: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, Kees Cook,
audit
On Mon, Aug 26 2024 at 01:29, syzbot wrote:
Cc:+ seccomp and audit folks
> syzbot found the following issue on:
>
> HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc
> dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c
> 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/47820545bc51/disk-6a7917c8.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com
>
> WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> Modules linked in:
> CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
> RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff
> RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246
> RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000
> RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728
> RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364
> R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000
> R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c
> FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> might_alloc include/linux/sched/mm.h:337 [inline]
> slab_pre_alloc_hook mm/slub.c:3987 [inline]
> slab_alloc_node mm/slub.c:4065 [inline]
> kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
> audit_buffer_alloc kernel/audit.c:1790 [inline]
> audit_log_start+0x15e/0xa30 kernel/audit.c:1912
> audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
> seccomp_log kernel/seccomp.c:1016 [inline]
> __seccomp_filter+0xb38/0x1fe0 kernel/seccomp.c:1305
> syscall_trace_enter+0xa8/0x150 kernel/entry/common.c:52
> syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline]
> syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline]
> do_syscall_64+0xcc/0x230 arch/x86/entry/common.c:79
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f4cf4d157e9
> Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 c7 c0 0f 00 00 00 0f 05 <0f> 1f 80 00 00 00 00 48 81 ec 48 01 00 00 49 89 d0 64 48 8b 04 25
> RSP: 002b:00007f4cf5b69b40 EFLAGS: 00000206 ORIG_RAX: 000000000000000f
> RAX: ffffffffffffffda RBX: 00007f4cf4f15f88 RCX: 00007f4cf4d157e9
> RDX: 00007f4cf5b69b40 RSI: 00007f4cf5b69c70 RDI: 0000000000000021
> RBP: 00007f4cf4f15f80 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000206 R12: 00007f4cf4f15f8c
> R13: 0000000000000000 R14: 00007fffe8828e10 R15: 00007fffe8828ef8
> </TASK>
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want 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] 7+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-09-02 8:37 ` Thomas Gleixner
@ 2024-09-03 19:22 ` Paul Moore
2024-09-03 19:24 ` Kees Cook
0 siblings, 1 reply; 7+ messages in thread
From: Paul Moore @ 2024-09-03 19:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, Kees Cook,
audit
On Mon, Sep 2, 2024 at 4:37 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, Aug 26 2024 at 01:29, syzbot wrote:
>
> Cc:+ seccomp and audit folks
>
> > syzbot found the following issue on:
> >
> > HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c
> > 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/47820545bc51/disk-6a7917c8.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com
> >
> > WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> > Modules linked in:
> > CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
> > RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> > Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff
> > RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246
> > RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000
> > RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728
> > RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364
> > R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000
> > R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c
> > FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> > <TASK>
> > might_alloc include/linux/sched/mm.h:337 [inline]
> > slab_pre_alloc_hook mm/slub.c:3987 [inline]
> > slab_alloc_node mm/slub.c:4065 [inline]
> > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
> > audit_buffer_alloc kernel/audit.c:1790 [inline]
> > audit_log_start+0x15e/0xa30 kernel/audit.c:1912
> > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
The audit_seccomp() function allocates an audit buffer using
GFP_KERNEL, which should be the source of the might_sleep. We can fix
that easily enough by moving to GFP_ATOMIC (either for just this code
path or all callers, need to check that), but I just want to confirm
that we can't sleep here? I haven't dug into the syscall code in a
while, so I don't recall all the details, but it seems odd to me that
we can't safely sleep here ...
> > seccomp_log kernel/seccomp.c:1016 [inline]
> > __seccomp_filter+0xb38/0x1fe0 kernel/seccomp.c:1305
> > syscall_trace_enter+0xa8/0x150 kernel/entry/common.c:52
> > syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline]
> > syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline]
> > do_syscall_64+0xcc/0x230 arch/x86/entry/common.c:79
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > RIP: 0033:0x7f4cf4d157e9
> > Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 c7 c0 0f 00 00 00 0f 05 <0f> 1f 80 00 00 00 00 48 81 ec 48 01 00 00 49 89 d0 64 48 8b 04 25
> > RSP: 002b:00007f4cf5b69b40 EFLAGS: 00000206 ORIG_RAX: 000000000000000f
> > RAX: ffffffffffffffda RBX: 00007f4cf4f15f88 RCX: 00007f4cf4d157e9
> > RDX: 00007f4cf5b69b40 RSI: 00007f4cf5b69c70 RDI: 0000000000000021
> > RBP: 00007f4cf4f15f80 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000206 R12: 00007f4cf4f15f8c
> > R13: 0000000000000000 R14: 00007fffe8828e10 R15: 00007fffe8828ef8
> > </TASK>
--
paul-moore.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-09-03 19:22 ` Paul Moore
@ 2024-09-03 19:24 ` Kees Cook
2024-09-03 20:54 ` Thomas Gleixner
0 siblings, 1 reply; 7+ messages in thread
From: Kees Cook @ 2024-09-03 19:24 UTC (permalink / raw)
To: Paul Moore
Cc: Thomas Gleixner, syzbot, linux-kernel, luto, peterz,
syzkaller-bugs, audit
On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote:
> On Mon, Sep 2, 2024 at 4:37 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Mon, Aug 26 2024 at 01:29, syzbot wrote:
> >
> > Cc:+ seccomp and audit folks
> >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c
> > > 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/47820545bc51/disk-6a7917c8.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com
> > >
> > > WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> > > Modules linked in:
> > > CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
> > > RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552
> > > Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff
> > > RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246
> > > RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000
> > > RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728
> > > RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364
> > > R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000
> > > R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c
> > > FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0
> > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > > Call Trace:
> > > <TASK>
> > > might_alloc include/linux/sched/mm.h:337 [inline]
> > > slab_pre_alloc_hook mm/slub.c:3987 [inline]
> > > slab_alloc_node mm/slub.c:4065 [inline]
> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
> > > audit_buffer_alloc kernel/audit.c:1790 [inline]
> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912
> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
>
> The audit_seccomp() function allocates an audit buffer using
> GFP_KERNEL, which should be the source of the might_sleep. We can fix
> that easily enough by moving to GFP_ATOMIC (either for just this code
> path or all callers, need to check that), but I just want to confirm
> that we can't sleep here? I haven't dug into the syscall code in a
> while, so I don't recall all the details, but it seems odd to me that
> we can't safely sleep here ...
I had a similar question.. this is at syscall entry time. What is
suddenly different here? We've been doing seccomp logging here for
years...
-Kees
--
Kees Cook
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-09-03 19:24 ` Kees Cook
@ 2024-09-03 20:54 ` Thomas Gleixner
2024-09-03 21:21 ` Paul Moore
2024-09-03 21:22 ` Aleksandr Nogikh
0 siblings, 2 replies; 7+ messages in thread
From: Thomas Gleixner @ 2024-09-03 20:54 UTC (permalink / raw)
To: Kees Cook, Paul Moore
Cc: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, audit
On Tue, Sep 03 2024 at 12:24, Kees Cook wrote:
> On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote:
>> > > might_alloc include/linux/sched/mm.h:337 [inline]
>> > > slab_pre_alloc_hook mm/slub.c:3987 [inline]
>> > > slab_alloc_node mm/slub.c:4065 [inline]
>> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
>> > > audit_buffer_alloc kernel/audit.c:1790 [inline]
>> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912
>> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
>>
>> The audit_seccomp() function allocates an audit buffer using
>> GFP_KERNEL, which should be the source of the might_sleep. We can fix
>> that easily enough by moving to GFP_ATOMIC (either for just this code
>> path or all callers, need to check that), but I just want to confirm
>> that we can't sleep here? I haven't dug into the syscall code in a
>> while, so I don't recall all the details, but it seems odd to me that
>> we can't safely sleep here ...
>
> I had a similar question.. this is at syscall entry time. What is
> suddenly different here? We've been doing seccomp logging here for
> years...
Correct.
syscall_enter_from_user_mode() enables interrupts. At that point
preempt_count is 0. So after that the task can sleep and schedule.
Nothing in the call chain leading up to the allocation disables
preemption or interrupts.
From the actual console log:
do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30
I have no idea how that state would leak accross schedule_timeout().
Thanks,
tglx
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-09-03 20:54 ` Thomas Gleixner
@ 2024-09-03 21:21 ` Paul Moore
2024-09-03 21:22 ` Aleksandr Nogikh
1 sibling, 0 replies; 7+ messages in thread
From: Paul Moore @ 2024-09-03 21:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, syzbot, linux-kernel, luto, peterz, syzkaller-bugs,
audit
On Tue, Sep 3, 2024 at 4:54 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, Sep 03 2024 at 12:24, Kees Cook wrote:
> > On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote:
> >> > > might_alloc include/linux/sched/mm.h:337 [inline]
> >> > > slab_pre_alloc_hook mm/slub.c:3987 [inline]
> >> > > slab_alloc_node mm/slub.c:4065 [inline]
> >> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
> >> > > audit_buffer_alloc kernel/audit.c:1790 [inline]
> >> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912
> >> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
> >>
> >> The audit_seccomp() function allocates an audit buffer using
> >> GFP_KERNEL, which should be the source of the might_sleep. We can fix
> >> that easily enough by moving to GFP_ATOMIC (either for just this code
> >> path or all callers, need to check that), but I just want to confirm
> >> that we can't sleep here? I haven't dug into the syscall code in a
> >> while, so I don't recall all the details, but it seems odd to me that
> >> we can't safely sleep here ...
> >
> > I had a similar question.. this is at syscall entry time. What is
> > suddenly different here? We've been doing seccomp logging here for
> > years...
>
> Correct.
>
> syscall_enter_from_user_mode() enables interrupts. At that point
> preempt_count is 0. So after that the task can sleep and schedule.
> Nothing in the call chain leading up to the allocation disables
> preemption or interrupts.
>
> From the actual console log:
>
> do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30
>
> I have no idea how that state would leak accross schedule_timeout().
Okay, with no obvious root cause and no reproducer, I'm going to
ignore this for now. If we start to see this pop up on real systems
and/or syzbot finds a reproducer we can dig into it more.
--
paul-moore.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start
2024-09-03 20:54 ` Thomas Gleixner
2024-09-03 21:21 ` Paul Moore
@ 2024-09-03 21:22 ` Aleksandr Nogikh
1 sibling, 0 replies; 7+ messages in thread
From: Aleksandr Nogikh @ 2024-09-03 21:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kees Cook, Paul Moore, syzbot, linux-kernel, luto, peterz,
syzkaller-bugs, audit
On Tue, Sep 3, 2024 at 10:54 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Tue, Sep 03 2024 at 12:24, Kees Cook wrote:
> > On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote:
> >> > > might_alloc include/linux/sched/mm.h:337 [inline]
> >> > > slab_pre_alloc_hook mm/slub.c:3987 [inline]
> >> > > slab_alloc_node mm/slub.c:4065 [inline]
> >> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092
> >> > > audit_buffer_alloc kernel/audit.c:1790 [inline]
> >> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912
> >> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007
> >>
> >> The audit_seccomp() function allocates an audit buffer using
> >> GFP_KERNEL, which should be the source of the might_sleep. We can fix
> >> that easily enough by moving to GFP_ATOMIC (either for just this code
> >> path or all callers, need to check that), but I just want to confirm
> >> that we can't sleep here? I haven't dug into the syscall code in a
> >> while, so I don't recall all the details, but it seems odd to me that
> >> we can't safely sleep here ...
> >
> > I had a similar question.. this is at syscall entry time. What is
> > suddenly different here? We've been doing seccomp logging here for
> > years...
>
> Correct.
>
> syscall_enter_from_user_mode() enables interrupts. At that point
> preempt_count is 0. So after that the task can sleep and schedule.
> Nothing in the call chain leading up to the allocation disables
> preemption or interrupts.
>
> From the actual console log:
>
> do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30
>
> I have no idea how that state would leak accross schedule_timeout().
>
There has been a spike in strange crash reports on linux-next lately,
supposedly due to this large patch series:
https://lore.kernel.org/all/20240727102732.960974693@infradead.org/
So if this report is not easily explainable, possibly it is best to
take it with a grain of salt..
Aleksandr
> Thanks,
>
> tglx
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-09-03 21:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-26 8:29 [syzbot] [kernel?] WARNING in audit_log_start syzbot
2024-09-02 8:37 ` Thomas Gleixner
2024-09-03 19:22 ` Paul Moore
2024-09-03 19:24 ` Kees Cook
2024-09-03 20:54 ` Thomas Gleixner
2024-09-03 21:21 ` Paul Moore
2024-09-03 21:22 ` Aleksandr Nogikh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox