From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 C866A175A75 for ; Mon, 9 Mar 2026 19:03:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773083038; cv=none; b=OIojovEP2RMustjA4lNbeiCpKRvwh57mp0g0rirSAQCFdAykAYJ8n0dqDTBNOQO73OETp9ZJ4AukbTA4fIiLF44kYZybAwcrYFTn2ln1LKhX/2h3Yt6Gl9NqA1Iv31m0rgEt/7j8AWt7lr4S1Foz/XCLWix77MqyQPHSRrOMCIo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773083038; c=relaxed/simple; bh=rwILhUZan+amNqmf+eGyJgqqtLh+qpDNWEGH04ys5Xw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RXnzLuu4uOfljae7okAzXleEYyi263ryJlXH17Je95GVuv0ORrZlYVnfuGcnZv3WtYMTvVLv3Y+h3xW+OVzrGCqqdMe69thHFqdZuOhuvz1NeFSqQlzOsFa9veYB7h7nIJBFT0tC6WpOL2x4KDLpreM0O5asnKjtRyxKJUxPwII= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=K4Bt3twn; arc=none smtp.client-ip=209.85.218.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="K4Bt3twn" Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b942424d231so470924266b.0 for ; Mon, 09 Mar 2026 12:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; t=1773083035; x=1773687835; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AN46rwVFm4AOM44t1Drekt08GTwc3bjzYdTKLuL7BI4=; b=K4Bt3twnZH3wdp1wQlMnPwrG/xDfYoAYi3fvocQdGp6Mv0VcCNvvAVE3WFPARNp+Pb 64q6OZFDA8NHEWsb5Qi8Om1beSkfc7bU3sz/8ZBSlrwwpjTJStox/oveQHwcM9XCNp5g BIBP7mo+IyQd9UohnopK4i2tTkYjup+25sgyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773083035; x=1773687835; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AN46rwVFm4AOM44t1Drekt08GTwc3bjzYdTKLuL7BI4=; b=FnHu31WlZ23TegWuupJ0H7RSo0fAab3x2swSYg0qLvyMPoaeyU2E/kgrDM/+DB09ba x59zeir5dFk8bg6wKKREjTpFmJDNa35jswDIBxY79V8mHu/eGfMtPSYV41bxkYBHyPpv 5ePWxByUcYaABichX0GxklxREB6S2JPIotIw1ZrxInYpesAwaCLVQbsPaoYP6MfTzxM2 cm68vSaAK5gi0eeNj5O4gRMMsHcpCJLLKPQr2sAxn3m/gQVwhAmfjRu44tTGijtVIkUk 5c7vE2l/btD17rtL2FyqV8Pe4S+v1mQhkWPkvtDj+ahR2ZqdSr3lUSnGFhcWuxWp+cjP NHKA== X-Forwarded-Encrypted: i=1; AJvYcCXHe2fWV/+ZL3r9AKJ65cH4QcuZgQWBz2u8GZ1cx9offxKz3sHUK7KGpUkoasnScH0hlY4baLvgMA==@vger.kernel.org X-Gm-Message-State: AOJu0YyViIXyanJ3R4YF98pUbZKHg6AzOLf3sBP+QaIvUOfwIKdw7XNn 1whTItLI5NUp12k9OD7HybRhRWsI4LkhhrSydgQbsF/2kfYkZOfeoBzrrMcvZbK2sOqeFvOz9e9 Qp1tGq2UAFQ== X-Gm-Gg: ATEYQzxd00EdP1FSWH0OdEpv8CJEyYaij3v9tcJ6AiVNihpt7zToo6q/ybJfaBTpekS M5c2kMOpLCTHoQ2XxjyOD8pgYeG2H/gBJaGoL6nXg9pKZwFQNlCb3n1HF4X9zoooEiu9d9AuDB4 oH9IeMrfDMI8p7W3usb3fpnIAEP/sDjRfRYyC2wI/rqs2F9wuN9yXku8qnFHNrJuw1VbGAom2c9 raaDWx5uiUYKJPqAWRV6S4udqK7uH5LEZzFkYRgyie3TRcexP5I8yn2xHwQHUeBl4tgN5EghE9J bXwEp4BLu2ZLtcSh2T9lo/fyMnO7E6KcCQsTSP9PaDKxseKCtZw3goQQlu3E7CQHLAs+YnHPqSL eua4WJ8u2YE2PgV15evGV2uUztdLaQnCE/Px8jB+/IIQzKB2SZGgyDKaHJW8Jqt6SyKVfu0xyuq wQAb3SNdwth+E6pfTflOoHWV24ON7Su+/KJ8USdSctAr3mX7X+D+EDsQhIMYr6NsmrqXcY71M= X-Received: by 2002:a17:907:94ca:b0:b96:ee7e:a66d with SMTP id a640c23a62f3a-b96ee7eb170mr306726466b.59.1773083034652; Mon, 09 Mar 2026 12:03:54 -0700 (PDT) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b942f13a3afsm409059766b.40.2026.03.09.12.03.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 12:03:54 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-b96d784828bso289197866b.3 for ; Mon, 09 Mar 2026 12:03:54 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVPBAkP+lxbfuJyMsvGgQQuxrd23uGM7RAfOfYCYC0FLXJ5WNWVuA3K55IGKDez+yAfpPlwVwPpgQ==@vger.kernel.org X-Received: by 2002:a17:907:961d:b0:b73:2b08:ac70 with SMTP id a640c23a62f3a-b942e01dec5mr664086466b.49.1773083034035; Mon, 09 Mar 2026 12:03:54 -0700 (PDT) Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <42AD516A-B078-40A5-94EE-80739B9883E7@kernel.dk> <453563bb-8dda-471a-901a-30ba9ff3f9c8@kernel.dk> In-Reply-To: From: Linus Torvalds Date: Mon, 9 Mar 2026 12:03:36 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: AaiRm53MY1MOcz8Gor__drnYc-ZpbeH_-ZI8u8KuP5BY2aDE9nyVEQOlYcLII70 Message-ID: Subject: Re: [PATCH v1] io_uring/register.c: fix NULL pointer dereference in io_register_resize_rings To: Jens Axboe Cc: Hao-Yu Yang , security@kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On Mon, 9 Mar 2026 at 11:35, Jens Axboe wrote: > > --- 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); The store-release doesn't actually make sense here. It just says "this store is visible after all previous stores". It can still be delayed arbitraritly, and migrate down into the locked regions, and be visible to other cpus much later. On x86, getting a lock will be a full memory barrier, but that's not true everywhere else: locks keep things *inside* the locked region inside the lock, but don't stop things *outside* the locked region from moving into it. End result: the smp_store_release does nothing. You should use a write barrier (or a smp_store_mb(), but that's expensive). But even *that* won't work - because the irq can already be running on another CPU, and maybe it already tested 'in_resize', and saw a zero, and then did that atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); afterwards. > @@ -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); On the release side, the store_release would make sense - the store is visible to others after all the other stores are done (including, obviously, the new 'rings' calue) But see above. This just doesn't *work*, because the irq - running on another cpu - will do the flag test and the cts->rings access as two separate operations. All these semantics means that 'in_resize' needs to basically be a lock. You can then use 'trylock()' in irq context *around* the whole sequence of using ctx->rings, to avoid disabling interrupts. Linus