From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 E7A3734BA2E for ; Mon, 9 Mar 2026 18:34:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773081283; cv=none; b=VIlsF9x6AdUcEEdaZao6J4yd83zIyImSGs3s8qz6UrDH2H7Cxy2zkDR7ATT++EDQyN/Y/4BRY8Hw5lma8s/PG8FPoE9+XUJVaAfVgNB518AwJz7tzEyFIxWat8K6Bl2D412Y530ZxOOKEL/mkokMwtNLATsNOX2JtgYJSx5QV00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773081283; c=relaxed/simple; bh=wLgP88adW/NXfqgFpyUSENvdkIgpvNTlpSOv8bLPNJU=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=Hzg4LYomUkeuurBrUUYyNElZA6C3Q7WONnS2/o1l8E5Zq5UeU89m5qMqCpUv3rTz9eBRZ+7yqOMR0oUJSJ0TerOTTJn6JlgMj1rQlqVo7fy9+dAgn73RWLENTulYM4KkHF37T3MY15hAIZqmNY57abz7uH88j1pXErp2/VK+aWg= 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=nJ8KnS2Z; arc=none smtp.client-ip=209.85.210.53 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="nJ8KnS2Z" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7d74fc959d8so731725a34.2 for ; Mon, 09 Mar 2026 11:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1773081278; x=1773686078; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=NRbx5017ZY07a0PYKqimSfteOEMGjnJ74HInu2odRm8=; b=nJ8KnS2ZxBrWOE8LFFEHZSm0YixgEMWdQ9QhuzWzscpsvmakTk6iNiOz+FZM/oEvDO 5KDhYvkb56Q62LcbMk80zVd3X479/PtIZJW1zyfKAuXbRKlDSGFJDpjD66OhcLdhkPCC SgbwIHwq9VgLIIP0+BaN3r6Bk8VCdUZcvbo+XAqkHcjnY2VvP2QH4mpBgLf6CGVc7jB/ B7Mj6QvHjHNUBByNhcQ339kkPraLFQEFEdiWah0V4gm7jSpDykp6MWLroIKj4zm34c+v tSBJ3cDsS8/I9YhbJy3DQNwol5kXFwgOOIk5IZuHxmAEILJmplu5ZZAi584HR9tUaxDb Sekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081278; x=1773686078; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=NRbx5017ZY07a0PYKqimSfteOEMGjnJ74HInu2odRm8=; b=DxXzLg+OtvMGgXZkqwMp1Z2vRaVxL5Wr9I1Kqzk8i8CkNt5tWGTTXPytwGr5dROYiE 8YYvSALcQ2417ZMStyiZC5LG1o/WrwGlVoGfM7N+5FAwnjaq0LSB7xDEF7IDsaVGLZ5U oXbuw5VMAO4bWJT3TQcsPRfahLnIIXCKm5UV/4QtipN45tbSQJ7TXYIVsH9YUkDhNVw8 Is2rKP0pJfMJ4dpSBVhhn2f6QZ6SY+X5JuHZ6Mv9PnSE6LYAIUUObpwqD7/kHEvPkuea YGC2ytH9mIDXRm4MlpdaBVRb/zVRCL9ZmCIWhl4SDuif0R5uD97GYgp29P9/yojR1sbR FQcw== X-Forwarded-Encrypted: i=1; AJvYcCW94NV9s2HrlHl527QPfkwjkTVWh7KJUXPIcaQhUUJ9Ld4MYMg4a4qOnUWWaDN6/d1DZkbukhYUdqkfT8w=@vger.kernel.org X-Gm-Message-State: AOJu0YyaMsPLVmCLXOsd5p3vdxi2tCSl4/OUmc/FMXLhd8Y5uP2dEQFM H30CuydDJrxgqighhUPOfpN87bXvJ+W1XOGPqv9/NuKBwllcVI4SRkxwNk8j1E0sy/Q= X-Gm-Gg: ATEYQzxx2kL7Ejzfof/QYEQmYYseeX9LsKZ8HtKlnAEaG8X9MdrJDGalpuHNUPYbh52 PHb22wnIIM9iFOB7pshIrDcqxvHuj4P6OondbOvYVZ0u4YIjEyI2vUtaZTitD2pWbdlDrNIQTon QfVA+7eJX/Pf06hmNtO9w+boTQBgz/dUW3mPt5JmSg+4+8BKL29FiWtENRMQ0BCYEG56LBFGbpy 0KQ9Zc6Q64BHdga+u/tqf83m4aYkuSFeMIcc7FUf9gm7QdFPKsz8IU/2uZk6PTAnRtlxH69RwMV kzmUL1mSXvh9JfoB3gpNEcGO5rQF0nqULzU4bPORXBKUUXow4BR9x2ijGhVPXuoSvRjBwls2/YN G6DDINm5fA/LCteIkZqsnTKIOx7YW7IK24+hlksBp4cnqDRHGtPBcwWKBfcv6cnqgaEE2fzDddn fN+fXeJU49yk0XqBPBtoy/1ziz1rjZf2YIwwB2tqhmelZRIobPcomOjZVpJJHASSgjDMp5dBiJB hbXu1zVuA== X-Received: by 2002:a05:6830:c0b:b0:7d7:5748:b99f with SMTP id 46e09a7af769-7d75748c60bmr882983a34.4.1773081277603; Mon, 09 Mar 2026 11:34:37 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d745cac199sm3232432a34.9.2026.03.09.11.34.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 11:34:37 -0700 (PDT) Message-ID: <453563bb-8dda-471a-901a-30ba9ff3f9c8@kernel.dk> Date: Mon, 9 Mar 2026 12:34:36 -0600 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: [PATCH v1] io_uring/register.c: fix NULL pointer dereference in io_register_resize_rings From: Jens Axboe To: Linus Torvalds Cc: Hao-Yu Yang , security@kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <42AD516A-B078-40A5-94EE-80739B9883E7@kernel.dk> Content-Language: en-US In-Reply-To: <42AD516A-B078-40A5-94EE-80739B9883E7@kernel.dk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/9/26 10:29 AM, Jens Axboe wrote: > On Mar 9, 2026, at 10:05?AM, Linus Torvalds wrote: >> >> ?On Mon, 9 Mar 2026 at 06:11, Jens Axboe wrote: >>> >>> You probably want something ala: >>> >>> mutex_lock(&ctx->mmap_lock); >>> spin_lock(&ctx->completion_lock(); >>> + local_irq_disable(); >> >> How could that ever work? >> >> Irqs will happily continue on other CPUs, so disabling interrupts is >> complete nonsense as far as I can tell - whether done with >> spin_lock_irq() *or* with local_irq_disable()/. >> >> So basically, touching ctx->rings from irq context in this section is >> simply not an option - or the rings pointer just needs to be updated >> atomically so that it doesn't matter. >> >> I assume this was tested in qemu on a single-core setup, so that >> fundamental mistake was hidden by an irrelevant configuration. >> >> Where is the actual oops - for some inexplicable reason that had been >> edited out, and it only had the call trace leading up toit? Based on >> the incomplete information and the faulting address of 0x24, I'm >> *guessing* that it is >> >> if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) >> atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); >> >> in io_req_normal_work_add(), but that may be complete garbage. >> >> So the actual fix may be to just make damn sure that >> IORING_SETUP_TASKRUN_FLAG is *not* set when the rings are resized. >> >> But for all I know, (a) I may be looking at entirely the wrong place >> and (b) there might be millions of other places that want to access >> ctx->rings, so the above may be the rantings of a crazy old man. > > Nah you?re totally right. I?m operating in few hours of sleep and on a > plane. I?ll take a closer look later. The flag mask protecting it is a > good idea, another one could be just a specific irq safe resize lock > would be better here. How about something like this? I don't particularly like using ->flags for this, as these are otherwise static after the ring has been set up. Hence it'd be better to to just use a separate value for this, ->in_resize, and use smp_load_acquire/release. The write side can be as expensive as we want it to be, as it's not a hot path at all. And the acquire read should light weight enough here. diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h index 3e4a82a6f817..428eb5b2c624 100644 --- a/include/linux/io_uring_types.h +++ b/include/linux/io_uring_types.h @@ -394,6 +394,7 @@ struct io_ring_ctx { atomic_t cq_wait_nr; atomic_t cq_timeouts; struct wait_queue_head cq_wait; + int in_resize; } ____cacheline_aligned_in_smp; /* timeouts */ diff --git a/io_uring/register.c b/io_uring/register.c index 3378014e51fb..048a1dcd9df1 100644 --- a/io_uring/register.c +++ b/io_uring/register.c @@ -575,6 +575,7 @@ static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg) * ctx->mmap_lock as well. Likewise, hold the completion lock over the * duration of the actual swap. */ + smp_store_release(&ctx->in_resize, 1); mutex_lock(&ctx->mmap_lock); spin_lock(&ctx->completion_lock); o.rings = ctx->rings; @@ -647,6 +648,7 @@ static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg) if (ctx->sq_data) io_sq_thread_unpark(ctx->sq_data); + smp_store_release(&ctx->in_resize, 0); return ret; } diff --git a/io_uring/tw.c b/io_uring/tw.c index 1ee2b8ab07c8..c66ffa787ec7 100644 --- a/io_uring/tw.c +++ b/io_uring/tw.c @@ -152,6 +152,13 @@ void tctx_task_work(struct callback_head *cb) WARN_ON_ONCE(ret); } +static void io_mark_taskrun(struct io_ring_ctx *ctx) +{ + if (ctx->flags & IORING_SETUP_TASKRUN_FLAG && + !smp_load_acquire(&ctx->in_resize)) + atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); +} + void io_req_local_work_add(struct io_kiocb *req, unsigned flags) { struct io_ring_ctx *ctx = req->ctx; @@ -206,6 +213,7 @@ void io_req_local_work_add(struct io_kiocb *req, unsigned flags) */ if (!head) { + io_mark_taskrun(ctx); if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); if (ctx->has_evfd) @@ -231,8 +239,7 @@ void io_req_normal_work_add(struct io_kiocb *req) if (!llist_add(&req->io_task_work.node, &tctx->task_list)) return; - if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) - atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); + io_mark_taskrun(ctx); /* SQPOLL doesn't need the task_work added, it'll run it itself */ if (ctx->flags & IORING_SETUP_SQPOLL) { -- Jens Axboe