From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (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 C5880344056 for ; Tue, 10 Mar 2026 08:51:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773132680; cv=none; b=t3Zd+sQRoacvbjwkQUu1mda0noonZV1kjj0tEhC6OWZaSoAWIlGUwLzUYZiTdzBc8LHbhoK3qUA6dh/zGH7SQiPpqZtptPGmEIqYHSenREdn8rxD/qs5B/M/UxZq3yo3jeu8iSTuzvRZ569e8m2eSCNfgi+j+XTuhIyKFw3GkqM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773132680; c=relaxed/simple; bh=Junyxo/AxC0i9kN4JSIPlzik1XZ2+ndba50wnqgyp2I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rYa6dQJhL7OVb7iH4ZYRUS1xwuqvB6oojjHoz1bzX8Si91C7u8wT573y6L7jtYYlgrgW7jYfxrm4jHnqdanwAask7gdm0pjaqGH1CN8QesSuBjr48pTek5HaHhTjLZEnhRwP6HHO5LAai6GYnCTc0yZi9qB5WdEuWP8SqDV5L1M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BLJ5rUbB; arc=none smtp.client-ip=209.85.210.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BLJ5rUbB" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-829a9d08644so2228627b3a.1 for ; Tue, 10 Mar 2026 01:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773132679; x=1773737479; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FEIJMcCOSlK/2cej+ULe0a9NbkGx/J/3ZpxAws4xPTk=; b=BLJ5rUbBKem18ev3AQCyA8h3kcjGDxTY5bp3h6Akf3fPfbZXkE5HE8H1/8x1qvMzRh tQOmlEI82Zl3xV2hN91WOKWehDP3RoMdbUg3dpPcYiZ2MTqonHHMwuI8qOttIsbIPHBz t7rGoBUkw5OfVggEVUO8zBQCWRUD2RpO9RBZEyt/1OSKm4PbVvNUcLD1wFDPM1jta0mt Jm6j85BQcgtSOjK3ILlbnECADt3MGuYh14nYdiw9jKQTLZ/dQ9/VEYHao2B4efjK2TKh Mu0o1Gfdvtb9XXjZKHq0dLzieJ/JwB1p9d22jnOjgxqxlt5jqXiGIyNAjLPnpHN3T5yp YIqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773132679; x=1773737479; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FEIJMcCOSlK/2cej+ULe0a9NbkGx/J/3ZpxAws4xPTk=; b=OS+l6zNxuVVllV4tP0uHqGch30KZD/m1jYnG9mFrK3h3NJ4F5LJhTJCCVslNw4l2qf 7OAeXi0oLeN5jLM8DdeoNJdwwcVp45P1AQDJxpHAubS4nfFycwMeCpN87KtUZqGeMnBV C/9qJSLIzJPm+mLHf8uDCVa8DjsoFeS/ke7SyZKbhX96LaFFipMB/iaEr3hu0uA3CZwG CaNEZ7+WpwfK6Ziy/jt/AarnQrVPIRdvOe3ejo9Ta+iCM/n78IsWhgSQljGHZ5wiCxoV 3KtT0ojOqyR4P7DOTav2jFSnAxbFqzjgw43hMLuQcV0Cc3mehlbV96hEOYoG+l1np/W/ pnrQ== X-Forwarded-Encrypted: i=1; AJvYcCUrriiDvrS9DHB9JAGyTPFo4JQ+b3dwxXgIHwCdDnEAi3rnWe6rMVfWGe5o43pMc7Klt8Cg9rKfM+Mc6rw=@vger.kernel.org X-Gm-Message-State: AOJu0YxvwrTZAQEAgwE3kprdNevgzjgzpX8c3sQHnUv4tEf1XXzxvCQl JFn0TvfTjRjbLiF/InoYWE7M1yoQCTVp/76x5WbPc45GD/5G5G9Q5cGc X-Gm-Gg: ATEYQzwraoffeUZ/0Nay4NyiZX7hzda2H9dybn0c/pQxFH7+gH37QGe7DArKMfHflCe G/MUwrLLPMuRac4kqD2JbcN3lXdWgUw6Z0GRhrPnN8nwAiBJ7UzccJvVzuc6AbxEb9j9NuQMONx yPZBQfL4f1mrcbIwlZkJaoN2vUeDHwABqqrjOyuP0gVoZzw0Poi84trvuVRvLcF3B30/AAnm4pz ADh8J8PwtABPPo51PbJUZxWAzktUjctOFN137gpQA7iIHX6DvqgQnc282kliZwR1ns+JiPGky6i JoJlguUhdeTuh9G8aZ/9u61AkmPQAezJz9ZRCJU5qozan2QEEUTS6tkUv9PgB2G9vQAUNYGhBTp wMeXiVf7Vpbfj3hJwbwxm1ZYmBbC0sEqYc+bdcmurx7o932j82xJEZUeR2p3tqj+kd6nQuKAKbd CfGKc6jUZLJVQLUuPZxV+XD4NwPPIZxPEVp00MohHfaGMhmmoh X-Received: by 2002:a05:6a21:700a:b0:398:a1ca:7a05 with SMTP id adf61e73a8af0-398a1ca8fd3mr4024883637.51.1773132679179; Tue, 10 Mar 2026 01:51:19 -0700 (PDT) Received: from naup-virtual-machine ([140.113.92.221]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c739e16cefcsm11171854a12.19.2026.03.10.01.51.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 01:51:18 -0700 (PDT) Date: Tue, 10 Mar 2026 16:51:15 +0800 From: Hao-Yu Yang To: Jens Axboe Cc: Linus Torvalds , security@kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] io_uring/register.c: fix NULL pointer dereference in io_register_resize_rings Message-ID: References: <42AD516A-B078-40A5-94EE-80739B9883E7@kernel.dk> <453563bb-8dda-471a-901a-30ba9ff3f9c8@kernel.dk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 09, 2026 at 01:22:10PM -0600, Jens Axboe wrote: > On 3/9/26 1:03 PM, Linus Torvalds wrote: > > 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. > > Agree - I think Pavel's suggestion to use an rcu protected pointer and > have the resize sync rcu is probably better though. As mentioned, resize > can be expensive, it's not a hot path operation. the local_work_add() > path is extremely hot, however. > > I'll take a look with fresh eyes tomorrow. > > -- > Jens Axboe Hello Yes, crash point is at if (!head) { if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); When access &ctx->rings->sq_flags. I removed it accidentally, yesterday.