[syzbot] [io-uring?] WARNING in __secure_computing

[syzbot] [io-uring?] WARNING in __secure_computing

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    2961f841b025 Merge tag 'turbostat-2026.02.14' of git://git..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1721315a580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e2f061f80b102378
dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=142edb3a580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-2961f841.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4f9939f81465/vmlinux-2961f841.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3f9babe832cd/bzImage-2961f841.xz

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

------------[ cut here ]------------
1
WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
Modules linked in:
CPU: 1 UID: 0 PID: 6077 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407
Code: 00 e8 96 52 fe ff e8 31 27 ff ff e8 fc 68 6b 00 bf 09 00 00 00 e8 82 f0 be ff e8 3d 79 6b 00 e9 06 fe ff ff e8 13 27 ff ff 90 <0f> 0b 90 e8 da 68 6b 00 bf 09 00 00 00 e8 60 f0 be ff e8 fb 26 ff
RSP: 0018:ffffc9000413fed0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000413ff48 RCX: ffffffff82097151
RDX: ffff888035c04900 RSI: ffffffff8209730d RDI: ffff888035c04900
RBP: 0000000000000003 R08: 0000000000000005 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000000 R12: 00000000000001b4
R13: 00000000000001b4 R14: ffff888035c04900 R15: 0000000000000001
FS:  0000555575c2e500(0000) GS:ffff8880d644a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f20e8a71fc0 CR3: 00000000373f5000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 syscall_trace_enter include/linux/entry-common.h:112 [inline]
 syscall_enter_from_user_mode_work include/linux/entry-common.h:156 [inline]
 syscall_enter_from_user_mode include/linux/entry-common.h:187 [inline]
 do_syscall_64+0x568/0xf80 arch/x86/entry/syscall_64.c:90
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f20e8b9c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd25984108 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
RAX: ffffffffffffffda RBX: 00007ffd259841f0 RCX: 00007f20e8b9c629
RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
RBP: 000000000000f6e1 R08: 0000000000000001 R09: 0000000000000000
R10: 0000001b2d120000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f20e8e15fac R14: 00007f20e8e15fa8 R15: 00007f20e8e15fa0
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

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

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

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

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

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

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

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Jens Axboe]

On 2/17/26 9:00 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    2961f841b025 Merge tag 'turbostat-2026.02.14' of git://git..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1721315a580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e2f061f80b102378
> dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=142edb3a580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-2961f841.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/4f9939f81465/vmlinux-2961f841.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3f9babe832cd/bzImage-2961f841.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> 1
> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
> Modules linked in:
> CPU: 1 UID: 0 PID: 6077 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:__secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407
> Code: 00 e8 96 52 fe ff e8 31 27 ff ff e8 fc 68 6b 00 bf 09 00 00 00 e8 82 f0 be ff e8 3d 79 6b 00 e9 06 fe ff ff e8 13 27 ff ff 90 <0f> 0b 90 e8 da 68 6b 00 bf 09 00 00 00 e8 60 f0 be ff e8 fb 26 ff
> RSP: 0018:ffffc9000413fed0 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: ffffc9000413ff48 RCX: ffffffff82097151
> RDX: ffff888035c04900 RSI: ffffffff8209730d RDI: ffff888035c04900
> RBP: 0000000000000003 R08: 0000000000000005 R09: 0000000000000003
> R10: 0000000000000003 R11: 0000000000000000 R12: 00000000000001b4
> R13: 00000000000001b4 R14: ffff888035c04900 R15: 0000000000000001
> FS:  0000555575c2e500(0000) GS:ffff8880d644a000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f20e8a71fc0 CR3: 00000000373f5000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  syscall_trace_enter include/linux/entry-common.h:112 [inline]
>  syscall_enter_from_user_mode_work include/linux/entry-common.h:156 [inline]
>  syscall_enter_from_user_mode include/linux/entry-common.h:187 [inline]
>  do_syscall_64+0x568/0xf80 arch/x86/entry/syscall_64.c:90
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f20e8b9c629
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007ffd25984108 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4
> RAX: ffffffffffffffda RBX: 00007ffd259841f0 RCX: 00007f20e8b9c629
> RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003
> RBP: 000000000000f6e1 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000001b2d120000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007f20e8e15fac R14: 00007f20e8e15fa8 R15: 00007f20e8e15fa0
>  </TASK>

Not io_uring, no seccomp label that I can find...

#syz set subsystems: kernel

-- 
Jens Axboe

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Kees Cook]

On Wed, Feb 18, 2026 at 09:27:07AM -0700, Jens Axboe wrote:
> On 2/17/26 9:00 PM, syzbot wrote:
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000
> > [...]
> > WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077

This is:

        /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
        case SECCOMP_MODE_DEAD:
                WARN_ON_ONCE(1);
                do_exit(SIGKILL);
                return -1;

It's nice to see we caught an impossible state! :) Now we just need to
figure out what the repro is doing.

> Not io_uring, no seccomp label that I can find...

Why do you say this? The reproducer sets up io_uring and then calls
seccomp:

int main(void)
{
...
  //  io_uring_enter arguments: [
  //    fd: fd_io_uring (resource)
  //    to_submit: int32 = 0x847ba (4 bytes)
  //    min_complete: int32 = 0x0 (4 bytes)
  //    flags: io_uring_enter_flags = 0xe (8 bytes)
  //    sigmask: nil
  //    size: len = 0x0 (8 bytes)
  //  ]
  syscall(
      __NR_io_uring_enter, /*fd=*/r[1], /*to_submit=*/0x847ba,
      /*min_complete=*/0,
      /*flags=IORING_ENTER_EXT_ARG|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/
      0xeul, /*sigmask=*/0ul, /*size=*/0ul);
  //  seccomp$SECCOMP_SET_MODE_FILTER_LISTENER arguments: [
  //    op: const = 0x1 (8 bytes)
  //    flags: seccomp_flags_listener = 0x0 (8 bytes)
  //    arg: ptr[in, sock_fprog] {
  //      sock_fprog {
  //        len: len = 0x1 (2 bytes)
  //        pad = 0x0 (6 bytes)
  //        filter: ptr[in, array[sock_filter]] {
  //          array[sock_filter] {
  //            sock_filter {
  //              code: int16 = 0x6 (2 bytes)
  //              jt: int8 = 0xff (1 bytes)
  //              jf: int8 = 0x1 (1 bytes)
  //              k: int32 = 0x3fff0000 (4 bytes)
  //            }
  //          }
  //        }
  //      }
  //    }
  //  ]
  //  returns fd_seccomp
  NONFAILING(*(uint16_t*)0x200000000240 = 1);
  NONFAILING(*(uint64_t*)0x200000000248 = 0x2000000003c0);
  NONFAILING(*(uint16_t*)0x2000000003c0 = 6);
  NONFAILING(*(uint8_t*)0x2000000003c2 = -1);
  NONFAILING(*(uint8_t*)0x2000000003c3 = 1);
  NONFAILING(*(uint32_t*)0x2000000003c4 = 0x3fff0000);
  syscall(__NR_seccomp, /*op=*/1ul, /*flags=*/0ul, /*arg=*/0x200000000240ul);
  return 0;
}

So something has gone weird here, I assume related to seccomp listener
vs io_uring and process death.

-Kees

-- 
Kees Cook

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Jens Axboe]

On 2/19/26 11:53 AM, Kees Cook wrote:
> On Wed, Feb 18, 2026 at 09:27:07AM -0700, Jens Axboe wrote:
>> On 2/17/26 9:00 PM, syzbot wrote:
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000
>>> [...]
>>> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
> 
> This is:
> 
>         /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
>         case SECCOMP_MODE_DEAD:
>                 WARN_ON_ONCE(1);
>                 do_exit(SIGKILL);
>                 return -1;
> 
> It's nice to see we caught an impossible state! :) Now we just need to
> figure out what the repro is doing.
> 
>> Not io_uring, no seccomp label that I can find...
> 
> Why do you say this? The reproducer sets up io_uring and then calls
> seccomp:

Because I don't see any related interaction there at all. As per usual,
the syz repro ends up doing some odd SQ tweaking, which results in a
bunch of readv and NOPs being issued. The former against signalfd. I
don't see anything odd on the io_uring side outside of that. Well
there's the usual nonsensical fuzzing io_uring_enter flag setting, like
SQ_* which don't make sense for the ring setup, but these are just
ignored.

It is possible that because of the tons of readv being queued that some
io-wq activity will be occuring, and that could slow down certain paths
like the signal handling. But seem orthogonal to me, as you could most
likely accomplish the same with userside threads too.

I could be wrong of course! Note that I'm gone until next week, so not
going to spend any time looking at this before then. Please do dive in
if you have time, though...

> int main(void)
> {
> ...
>   //  io_uring_enter arguments: [
>   //    fd: fd_io_uring (resource)
>   //    to_submit: int32 = 0x847ba (4 bytes)
>   //    min_complete: int32 = 0x0 (4 bytes)
>   //    flags: io_uring_enter_flags = 0xe (8 bytes)
>   //    sigmask: nil
>   //    size: len = 0x0 (8 bytes)
>   //  ]
>   syscall(
>       __NR_io_uring_enter, /*fd=*/r[1], /*to_submit=*/0x847ba,
>       /*min_complete=*/0,
>       /*flags=IORING_ENTER_EXT_ARG|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/
>       0xeul, /*sigmask=*/0ul, /*size=*/0ul);
>   //  seccomp$SECCOMP_SET_MODE_FILTER_LISTENER arguments: [
>   //    op: const = 0x1 (8 bytes)
>   //    flags: seccomp_flags_listener = 0x0 (8 bytes)
>   //    arg: ptr[in, sock_fprog] {
>   //      sock_fprog {
>   //        len: len = 0x1 (2 bytes)
>   //        pad = 0x0 (6 bytes)
>   //        filter: ptr[in, array[sock_filter]] {
>   //          array[sock_filter] {
>   //            sock_filter {
>   //              code: int16 = 0x6 (2 bytes)
>   //              jt: int8 = 0xff (1 bytes)
>   //              jf: int8 = 0x1 (1 bytes)
>   //              k: int32 = 0x3fff0000 (4 bytes)
>   //            }
>   //          }
>   //        }
>   //      }
>   //    }
>   //  ]
>   //  returns fd_seccomp
>   NONFAILING(*(uint16_t*)0x200000000240 = 1);
>   NONFAILING(*(uint64_t*)0x200000000248 = 0x2000000003c0);
>   NONFAILING(*(uint16_t*)0x2000000003c0 = 6);
>   NONFAILING(*(uint8_t*)0x2000000003c2 = -1);
>   NONFAILING(*(uint8_t*)0x2000000003c3 = 1);
>   NONFAILING(*(uint32_t*)0x2000000003c4 = 0x3fff0000);
>   syscall(__NR_seccomp, /*op=*/1ul, /*flags=*/0ul, /*arg=*/0x200000000240ul);
>   return 0;
> }
> 
> So something has gone weird here, I assume related to seccomp listener
> vs io_uring and process death.

See above on potentially lots of threads being kicked off. But probably
reproducing this first would be a good step towards fixing it.

-- 
Jens Axboe

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Jens Axboe]

On 2/20/26 6:44 AM, Jens Axboe wrote:
> On 2/19/26 11:53 AM, Kees Cook wrote:
>> On Wed, Feb 18, 2026 at 09:27:07AM -0700, Jens Axboe wrote:
>>> On 2/17/26 9:00 PM, syzbot wrote:
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000
>>>> [...]
>>>> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
>>
>> This is:
>>
>>         /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
>>         case SECCOMP_MODE_DEAD:
>>                 WARN_ON_ONCE(1);
>>                 do_exit(SIGKILL);
>>                 return -1;
>>
>> It's nice to see we caught an impossible state! :) Now we just need to
>> figure out what the repro is doing.
>>
>>> Not io_uring, no seccomp label that I can find...
>>
>> Why do you say this? The reproducer sets up io_uring and then calls
>> seccomp:
> 
> Because I don't see any related interaction there at all. As per usual,
> the syz repro ends up doing some odd SQ tweaking, which results in a
> bunch of readv and NOPs being issued. The former against signalfd. I
> don't see anything odd on the io_uring side outside of that. Well
> there's the usual nonsensical fuzzing io_uring_enter flag setting, like
> SQ_* which don't make sense for the ring setup, but these are just
> ignored.
> 
> It is possible that because of the tons of readv being queued that some
> io-wq activity will be occuring, and that could slow down certain paths
> like the signal handling. But seem orthogonal to me, as you could most
> likely accomplish the same with userside threads too.
> 
> I could be wrong of course! Note that I'm gone until next week, so not
> going to spend any time looking at this before then. Please do dive in
> if you have time, though...
> 
>> int main(void)
>> {
>> ...
>>   //  io_uring_enter arguments: [
>>   //    fd: fd_io_uring (resource)
>>   //    to_submit: int32 = 0x847ba (4 bytes)
>>   //    min_complete: int32 = 0x0 (4 bytes)
>>   //    flags: io_uring_enter_flags = 0xe (8 bytes)
>>   //    sigmask: nil
>>   //    size: len = 0x0 (8 bytes)
>>   //  ]
>>   syscall(
>>       __NR_io_uring_enter, /*fd=*/r[1], /*to_submit=*/0x847ba,
>>       /*min_complete=*/0,
>>       /*flags=IORING_ENTER_EXT_ARG|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/
>>       0xeul, /*sigmask=*/0ul, /*size=*/0ul);
>>   //  seccomp$SECCOMP_SET_MODE_FILTER_LISTENER arguments: [
>>   //    op: const = 0x1 (8 bytes)
>>   //    flags: seccomp_flags_listener = 0x0 (8 bytes)
>>   //    arg: ptr[in, sock_fprog] {
>>   //      sock_fprog {
>>   //        len: len = 0x1 (2 bytes)
>>   //        pad = 0x0 (6 bytes)
>>   //        filter: ptr[in, array[sock_filter]] {
>>   //          array[sock_filter] {
>>   //            sock_filter {
>>   //              code: int16 = 0x6 (2 bytes)
>>   //              jt: int8 = 0xff (1 bytes)
>>   //              jf: int8 = 0x1 (1 bytes)
>>   //              k: int32 = 0x3fff0000 (4 bytes)
>>   //            }
>>   //          }
>>   //        }
>>   //      }
>>   //    }
>>   //  ]
>>   //  returns fd_seccomp
>>   NONFAILING(*(uint16_t*)0x200000000240 = 1);
>>   NONFAILING(*(uint64_t*)0x200000000248 = 0x2000000003c0);
>>   NONFAILING(*(uint16_t*)0x2000000003c0 = 6);
>>   NONFAILING(*(uint8_t*)0x2000000003c2 = -1);
>>   NONFAILING(*(uint8_t*)0x2000000003c3 = 1);
>>   NONFAILING(*(uint32_t*)0x2000000003c4 = 0x3fff0000);
>>   syscall(__NR_seccomp, /*op=*/1ul, /*flags=*/0ul, /*arg=*/0x200000000240ul);
>>   return 0;
>> }
>>
>> So something has gone weird here, I assume related to seccomp listener
>> vs io_uring and process death.
> 
> See above on potentially lots of threads being kicked off. But probably
> reproducing this first would be a good step towards fixing it.

No threads are being kicked off - from strace, this seems to be the key:

seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=1, filter=0x2000000003c0}) = 0
exit_group(0)                           = 231
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
exit_group(11)    

as that WARN_ON_ONCE() in the report is indeed triggered off the
2nd exit_group() syscall.

-- 
Jens Axboe

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Kees Cook]

On Mon, Feb 23, 2026 at 12:15:17PM -0700, Jens Axboe wrote:
> On 2/20/26 6:44 AM, Jens Axboe wrote:
> > On 2/19/26 11:53 AM, Kees Cook wrote:
> >> On Wed, Feb 18, 2026 at 09:27:07AM -0700, Jens Axboe wrote:
> >>> On 2/17/26 9:00 PM, syzbot wrote:
> >>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13256722580000
> >>>> [...]
> >>>> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077
> >>
> >> This is:
> >>
> >>         /* Surviving SECCOMP_RET_KILL_* must be proactively impossible. */
> >>         case SECCOMP_MODE_DEAD:
> >>                 WARN_ON_ONCE(1);
> >>                 do_exit(SIGKILL);
> >>                 return -1;
> >>
> >> It's nice to see we caught an impossible state! :) Now we just need to
> >> figure out what the repro is doing.
> >>
> >>> Not io_uring, no seccomp label that I can find...
> >>
> >> Why do you say this? The reproducer sets up io_uring and then calls
> >> seccomp:
> > 
> > Because I don't see any related interaction there at all. As per usual,
> > the syz repro ends up doing some odd SQ tweaking, which results in a
> > bunch of readv and NOPs being issued. The former against signalfd. I
> > don't see anything odd on the io_uring side outside of that. Well
> > there's the usual nonsensical fuzzing io_uring_enter flag setting, like
> > SQ_* which don't make sense for the ring setup, but these are just
> > ignored.
> > 
> > It is possible that because of the tons of readv being queued that some
> > io-wq activity will be occuring, and that could slow down certain paths
> > like the signal handling. But seem orthogonal to me, as you could most
> > likely accomplish the same with userside threads too.
> > 
> > I could be wrong of course! Note that I'm gone until next week, so not
> > going to spend any time looking at this before then. Please do dive in
> > if you have time, though...
> > 
> >> int main(void)
> >> {
> >> ...
> >>   //  io_uring_enter arguments: [
> >>   //    fd: fd_io_uring (resource)
> >>   //    to_submit: int32 = 0x847ba (4 bytes)
> >>   //    min_complete: int32 = 0x0 (4 bytes)
> >>   //    flags: io_uring_enter_flags = 0xe (8 bytes)
> >>   //    sigmask: nil
> >>   //    size: len = 0x0 (8 bytes)
> >>   //  ]
> >>   syscall(
> >>       __NR_io_uring_enter, /*fd=*/r[1], /*to_submit=*/0x847ba,
> >>       /*min_complete=*/0,
> >>       /*flags=IORING_ENTER_EXT_ARG|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/
> >>       0xeul, /*sigmask=*/0ul, /*size=*/0ul);
> >>   //  seccomp$SECCOMP_SET_MODE_FILTER_LISTENER arguments: [
> >>   //    op: const = 0x1 (8 bytes)
> >>   //    flags: seccomp_flags_listener = 0x0 (8 bytes)
> >>   //    arg: ptr[in, sock_fprog] {
> >>   //      sock_fprog {
> >>   //        len: len = 0x1 (2 bytes)
> >>   //        pad = 0x0 (6 bytes)
> >>   //        filter: ptr[in, array[sock_filter]] {
> >>   //          array[sock_filter] {
> >>   //            sock_filter {
> >>   //              code: int16 = 0x6 (2 bytes)
> >>   //              jt: int8 = 0xff (1 bytes)
> >>   //              jf: int8 = 0x1 (1 bytes)
> >>   //              k: int32 = 0x3fff0000 (4 bytes)
> >>   //            }
> >>   //          }
> >>   //        }
> >>   //      }
> >>   //    }
> >>   //  ]
> >>   //  returns fd_seccomp
> >>   NONFAILING(*(uint16_t*)0x200000000240 = 1);
> >>   NONFAILING(*(uint64_t*)0x200000000248 = 0x2000000003c0);
> >>   NONFAILING(*(uint16_t*)0x2000000003c0 = 6);
> >>   NONFAILING(*(uint8_t*)0x2000000003c2 = -1);
> >>   NONFAILING(*(uint8_t*)0x2000000003c3 = 1);
> >>   NONFAILING(*(uint32_t*)0x2000000003c4 = 0x3fff0000);
> >>   syscall(__NR_seccomp, /*op=*/1ul, /*flags=*/0ul, /*arg=*/0x200000000240ul);
> >>   return 0;
> >> }
> >>
> >> So something has gone weird here, I assume related to seccomp listener
> >> vs io_uring and process death.
> > 
> > See above on potentially lots of threads being kicked off. But probably
> > reproducing this first would be a good step towards fixing it.
> 
> No threads are being kicked off - from strace, this seems to be the key:
> 
> seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=1, filter=0x2000000003c0}) = 0
> exit_group(0)                           = 231
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=NULL} ---
> exit_group(11)    
> 
> as that WARN_ON_ONCE() in the report is indeed triggered off the
> 2nd exit_group() syscall.

Thank you for tracking this down! I've been busy with fixing my rc1
kmalloc_obj breakages and didn't have time to look at this more.

-- 
Kees Cook

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Oleg Nesterov]

On 02/17, syzbot wrote:
>
> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077

#syz test

So signalfd_dequeue() is called by get_signal() -> task_work_run(), the work
was queued by io_uring... Thanks Kusaram.

Obviously this is not the right fix (and we should not blame io_uring), but
lets test to ensure.

Oleg.
---

diff --git a/fs/signalfd.c b/fs/signalfd.c
index dff53745e352..8819dea943f8 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -158,6 +158,9 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 	ssize_t ret;
 	DECLARE_WAITQUEUE(wait, current);
 
+	if (current->seccomp.mode == SECCOMP_MODE_FILTER + 1) // SECCOMP_MODE_DEAD
+		return -EINTR;
+
 	spin_lock_irq(&current->sighand->siglock);
 	ret = dequeue_signal(&ctx->sigmask, info, &type);
 	switch (ret) {

Re: [syzbot] [kernel] WARNING in __secure_computing

[syzbot]

Hello,

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

Reported-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com
Tested-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com

Tested on:

commit:         7ca6d1cf Merge tag 'powerpc-7.0-4' of git://git.kernel..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=106df3d6580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4f34697150c7a709
dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12f9946a580000

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

Re: [syzbot] [io-uring?] WARNING in __secure_computing

[Oleg Nesterov]

On 02/17, syzbot wrote:
>
> WARNING: kernel/seccomp.c:1407 at __secure_computing+0x2ae/0x2e0 kernel/seccomp.c:1407, CPU#1: syz.0.17/6077

#syz test

Lets try the approach suggested by Kusaram.
I don't see a better fix.

Oleg.
---

diff --git a/fs/signalfd.c b/fs/signalfd.c
index dff53745e352..107a83336657 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -48,17 +48,30 @@ static int signalfd_release(struct inode *inode, struct file *file)
 	return 0;
 }
 
+static void mk_sigmask(struct signalfd_ctx *ctx, sigset_t *sigmask)
+{
+	struct k_sigaction *k = current->sighand->action;
+	int n;
+
+	*sigmask = ctx->sigmask;
+	for (n = 1; n <= _NSIG; ++n, ++k) {
+		if (k->sa.sa_flags & SA_IMMUTABLE)
+			sigaddset(sigmask, n);
+	}
+}
+
 static __poll_t signalfd_poll(struct file *file, poll_table *wait)
 {
 	struct signalfd_ctx *ctx = file->private_data;
 	__poll_t events = 0;
+	sigset_t sigmask;
 
 	poll_wait(file, &current->sighand->signalfd_wqh, wait);
 
 	spin_lock_irq(&current->sighand->siglock);
-	if (next_signal(&current->pending, &ctx->sigmask) ||
-	    next_signal(&current->signal->shared_pending,
-			&ctx->sigmask))
+	mk_sigmask(ctx, &sigmask);
+	if (next_signal(&current->pending, &sigmask) ||
+	    next_signal(&current->signal->shared_pending, &sigmask))
 		events |= EPOLLIN;
 	spin_unlock_irq(&current->sighand->siglock);
 
@@ -155,11 +168,13 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 				int nonblock)
 {
 	enum pid_type type;
-	ssize_t ret;
 	DECLARE_WAITQUEUE(wait, current);
+	sigset_t sigmask;
+	ssize_t ret;
 
 	spin_lock_irq(&current->sighand->siglock);
-	ret = dequeue_signal(&ctx->sigmask, info, &type);
+	mk_sigmask(ctx, &sigmask);
+	ret = dequeue_signal(&sigmask, info, &type);
 	switch (ret) {
 	case 0:
 		if (!nonblock)
@@ -174,7 +189,7 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 	add_wait_queue(&current->sighand->signalfd_wqh, &wait);
 	for (;;) {
 		set_current_state(TASK_INTERRUPTIBLE);
-		ret = dequeue_signal(&ctx->sigmask, info, &type);
+		ret = dequeue_signal(&sigmask, info, &type);
 		if (ret != 0)
 			break;
 		if (signal_pending(current)) {
@@ -184,6 +199,7 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 		spin_unlock_irq(&current->sighand->siglock);
 		schedule();
 		spin_lock_irq(&current->sighand->siglock);
+		mk_sigmask(ctx, &sigmask);
 	}
 	spin_unlock_irq(&current->sighand->siglock);
 

Re: [syzbot] [kernel] WARNING in __secure_computing

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
lost connection to test machine



Tested on:

commit:         3aae9383 Merge tag 'input-for-v7.0-rc6' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a6cdda580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4f34697150c7a709
dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1246cdda580000

Re: [syzbot] [kernel] WARNING in __secure_computing

[Oleg Nesterov]

On 04/05, syzbot wrote:
>
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> lost connection to test machine

I can't believe it ;)

> console output: https://syzkaller.appspot.com/x/log.txt?x=17a6cdda580000

	qemu-system-x86_64: hw/ide/core.c:934: ide_dma_cb: Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
	Connection to localhost closed by remote host.

certainly unrelated.

Please retest.

#syz test


diff --git a/fs/signalfd.c b/fs/signalfd.c
index dff53745e352..107a83336657 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -48,17 +48,30 @@ static int signalfd_release(struct inode *inode, struct file *file)
 	return 0;
 }
 
+static void mk_sigmask(struct signalfd_ctx *ctx, sigset_t *sigmask)
+{
+	struct k_sigaction *k = current->sighand->action;
+	int n;
+
+	*sigmask = ctx->sigmask;
+	for (n = 1; n <= _NSIG; ++n, ++k) {
+		if (k->sa.sa_flags & SA_IMMUTABLE)
+			sigaddset(sigmask, n);
+	}
+}
+
 static __poll_t signalfd_poll(struct file *file, poll_table *wait)
 {
 	struct signalfd_ctx *ctx = file->private_data;
 	__poll_t events = 0;
+	sigset_t sigmask;
 
 	poll_wait(file, &current->sighand->signalfd_wqh, wait);
 
 	spin_lock_irq(&current->sighand->siglock);
-	if (next_signal(&current->pending, &ctx->sigmask) ||
-	    next_signal(&current->signal->shared_pending,
-			&ctx->sigmask))
+	mk_sigmask(ctx, &sigmask);
+	if (next_signal(&current->pending, &sigmask) ||
+	    next_signal(&current->signal->shared_pending, &sigmask))
 		events |= EPOLLIN;
 	spin_unlock_irq(&current->sighand->siglock);
 
@@ -155,11 +168,13 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 				int nonblock)
 {
 	enum pid_type type;
-	ssize_t ret;
 	DECLARE_WAITQUEUE(wait, current);
+	sigset_t sigmask;
+	ssize_t ret;
 
 	spin_lock_irq(&current->sighand->siglock);
-	ret = dequeue_signal(&ctx->sigmask, info, &type);
+	mk_sigmask(ctx, &sigmask);
+	ret = dequeue_signal(&sigmask, info, &type);
 	switch (ret) {
 	case 0:
 		if (!nonblock)
@@ -174,7 +189,7 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 	add_wait_queue(&current->sighand->signalfd_wqh, &wait);
 	for (;;) {
 		set_current_state(TASK_INTERRUPTIBLE);
-		ret = dequeue_signal(&ctx->sigmask, info, &type);
+		ret = dequeue_signal(&sigmask, info, &type);
 		if (ret != 0)
 			break;
 		if (signal_pending(current)) {
@@ -184,6 +199,7 @@ static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, kernel_siginfo_t *info
 		spin_unlock_irq(&current->sighand->siglock);
 		schedule();
 		spin_lock_irq(&current->sighand->siglock);
+		mk_sigmask(ctx, &sigmask);
 	}
 	spin_unlock_irq(&current->sighand->siglock);
 

Re: [syzbot] [kernel] WARNING in __secure_computing

[syzbot]

Hello,

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

Reported-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com
Tested-by: syzbot+0a4c46806941297fecb9@syzkaller.appspotmail.com

Tested on:

commit:         3aae9383 Merge tag 'input-for-v7.0-rc6' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11dc21ca580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=4f34697150c7a709
dashboard link: https://syzkaller.appspot.com/bug?extid=0a4c46806941297fecb9
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch:          https://syzkaller.appspot.com/x/patch.diff?x=141275da580000

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