From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A619348865 for ; Fri, 20 Feb 2026 13:44:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771595098; cv=none; b=aTBhMSmTdyjqpm+6wxFObOUXYqAPULTXGqOnWTqbjU/qTJWBjXdxyfAmDW/UrqHiuOnp9hAgH488SYLTLWfH7yHmVrBDO5fdOsQ/DA5YTlUYgfhvLXF5LyMC2FVbhCLTkut+1RGLhqqKV4hiU0PVLdEKfwUHRMBA0DUc5yc3WdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771595098; c=relaxed/simple; bh=kI5Clb0yGAyWnRWKZjSsWTSpgcQmJC5g3S7r/17wMAY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e0pWH9zAYxxkw/NAYxC7cJPLLUMnWxYpIeLcWC9dXBz6pHAlBZOUUUfqJdFtPG/5VdXcUc/Zmv9y8RcdcJFV2UHsMQHuoMvYUNycFaJTRo5o93yn3c5SE+ErscCBaWM2aYdVAmzhpzVn80U5ieToxg9mrkpj9CXdGLOfkc/Z7aI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=IxXpJ3JZ; arc=none smtp.client-ip=209.85.167.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="IxXpJ3JZ" Received: by mail-oi1-f193.google.com with SMTP id 5614622812f47-463967f35d7so1296707b6e.1 for ; Fri, 20 Feb 2026 05:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1771595095; x=1772199895; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YEPBAqSJxDhbFA+s3a3XAj9+X2vk2K8DNtZkBh8tQHY=; b=IxXpJ3JZfHcd8SKXnFFkGI20M7jw+Xkk1g4RgXjccqD0eWdlIFGeKRKpN0ulW/5ylr IxD1Ee1AOJNx+YLyLxpkaKiBC+NZz5PPj9iOPjeZPKAyAUk98/mM2ekY4gUpIntnqZLw 11NPCSF1DZip/dey0PJ6lHsLwWvmep7enti4IGWump9j1wa1mHEsk1vK1o0uk3dLYWaJ Cp2fJ3zrYacc4MHrmC7l6eXdpoZV/SQq6AdblYn8zx3m9qvTwoD4gmFGDjQbYwvr5Fc0 SN67bZPoVhwTU6onpaDCDr92H39BJVvxiXmXkCplzhCdK3kAFIbJMKwhiU84vJ7CAFAi d65w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771595095; x=1772199895; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YEPBAqSJxDhbFA+s3a3XAj9+X2vk2K8DNtZkBh8tQHY=; b=nZOyVdbS2dL2h1hF2V9uyBXmU0PsHNCeS6XWq2PE8UZz6uGsXWi9QZrRkjUC2gw27I DBf0a7l22jm2jB+47DuBgG5SPg6nTxnInXcismdII7FfGVN69XAr+ooSY/jbh875QWS3 LMMbYbLVIw232jA3shbnIe1LRDIUxrP4lYeFSB5WpwfBij16JjdhhGOs5ZGpjthjs/JU Dhue6ectuyNuKo11zP6LaJ0tLX6efDTAM/7BXx9wpX6Muw/yYQ/YPNaDbu2NYe8u7HO0 x7nvOAkIovQ/CBjGS5K34xae8xaizQJG2V9qnEGDNJ/kniJ3HozK2T4u0aaIqZ7YbCDE uMUg== X-Forwarded-Encrypted: i=1; AJvYcCXnTz8Ky6cGNNOmn8390ujq4lNffYJdDfaBmySav/9C74B1fXGBYDSpnIwRXYW0chOdf++cwq8qoCkRhrM=@vger.kernel.org X-Gm-Message-State: AOJu0YxP3OpiLHHYcZmK2vV4kDdgRlHlCrxi9OINEcZ+7xFjjk5gG6NT LCxrG2L0lq2WEQhHJl3BdTPhhO+GcTyVTI2JZjJo5Ml9smDp7e2aTC/d7WaUVGjyq6POJsbbFGV QEgttzvG5iw== X-Gm-Gg: AZuq6aLNZK4NcvvFJXdYcjWTUTFmHtg4/gcD24RiKIjh75CswjB9X6K2269LEmm6GEk GapCScKH3+e1N2ENfxVLYbZzWZRcxxxiOO5kauqsYS8afjMQ/auGvJo+UzmVnB/r8bQS9tUH6Y3 Z56tlNooTBL1B5kimaJ8aRm/TElL0IBLUkPKgRTRQ8xZLIKRwDG3TPAlJiz/ShHW27vj3yxN/0J GW39FJ9jIvo5hnbjpNEa2gaCKRe8piGTKah3WkC/MQna9sIviAQNdaMVb0ljSGQnfN5eIpAQJ0Z o8leRe0uAI1/Ke+nrc0VFh4CBLNwZ2PBCGuNu1HBfL/SGqZGvj45JQKha6gqr2my7WSaUn3mRvI Gzp4ABVg/Tj+At6U0q/33tjV/zMVsKHm1VSyBiECi9KcPN58UEdDtbfKvmYCxYhFWL6pTK9F/qJ xtGwWK5jI8cu/49hTc1lhNo28v/nnsy9zRGMIWn1p6iaynH4p2DPvvFc4oeiiAJYHOW+cytOPJZ BZbVE7c2KwGbg== X-Received: by 2002:a05:6808:f11:b0:45f:2788:b006 with SMTP id 5614622812f47-4643ba958fbmr1020325b6e.0.1771595094998; Fri, 20 Feb 2026 05:44:54 -0800 (PST) Received: from [172.25.209.35] ([187.223.170.195]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-40ee06756easm24302859fac.13.2026.02.20.05.44.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Feb 2026 05:44:54 -0800 (PST) Message-ID: <7d955b00-8cbf-4b09-9733-2c0d65e84e6e@kernel.dk> Date: Fri, 20 Feb 2026 06:44:53 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [syzbot] [io-uring?] WARNING in __secure_computing To: Kees Cook Cc: syzbot , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net, syzkaller-bugs@googlegroups.com, wad@chromium.org References: <69953966.a70a0220.2c38d7.0111.GAE@google.com> <202602191048.395EE1E@keescook> Content-Language: en-US From: Jens Axboe In-Reply-To: <202602191048.395EE1E@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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