From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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 B1DAE3BD628 for ; Mon, 9 Mar 2026 13:11:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773061898; cv=none; b=N5VCZdFZgKWmFpnQsG2pSZ7BZv+sgtgGsSffFz3lcIk12ejdmexds+SQWSN4GkI/XDosUcwr14eoq+Y7giFKlEc4rBqwXMx/ROMB92tO6qSHT1Py+o3ePiei+rKXVXUQk2UJA1isr7GKyTDzcbamtZK9z8z8+Y9rVEZCwYUNiC4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773061898; c=relaxed/simple; bh=oeob2fuLyQlPnO6SuJrLZeO3C4L6X4wU9QdohmlwS7A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hcvj7hHBd25MEPz7wtOj5UX8Esbge4pCEDbGm04f55feiqVrbUI7MRUlqEJmT2tev98I9+WNjwZbKLGvoOY9WSS+EUlduXB3BMMDAF+YRrPk5jtjNghS57tFAOPp3sUYLSwXnVOJwZHLNzJjhdYKSxEuYqb5Cz8CeeGWDU4N4uU= 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=uxxyQxWp; arc=none smtp.client-ip=209.85.222.174 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="uxxyQxWp" Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-8cd8a189f44so89015785a.0 for ; Mon, 09 Mar 2026 06:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1773061893; x=1773666693; 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=+j399pLZ+uCFFZegnh7B/GLRkXzNzBj7hwY8ivxyDs4=; b=uxxyQxWpvW0ywA+OjJAvo9klrZb9rc3wJCjGcpGQf5aCL7gMGnzzrrfc+Hy7llCnna Cj9VhcijXOvcoW5CByFrHEpCucN7A5zbpR+6cWtdc7dzGzel2GAhR4jgZ2U09VUjk5mq yRSNFHqCK5+FVlUFmBOZJpRTRzVz5N1Rw5//gCF/zT8jXPuEkYVAKk7K6u8emCDwmmG8 Yo+N4hD3QnDPoe+i4EEnHSz7+Hyq2KDMCUCLlEk4JHVn1reTD7KAUqQBsDeYM3sq3d02 aa1dqoaOWj2eJGON4u13/Oz7MkEjE5yAq6DOphjDg/EBvc9sJbljLzFiTcZyvB96CIyL M3Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773061893; x=1773666693; 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=+j399pLZ+uCFFZegnh7B/GLRkXzNzBj7hwY8ivxyDs4=; b=Ul3dVVglb73GHJku0UOAVVuIfAmzJ6GoVtwIhQJxhRJkb1ZbeM2ZmDX+iowzevJVrw 8403iEBReWmaXj3Mf0atNKc1ysZttoSB0z+GkIfVXTO4BWqwuLwXPfWcFCHRz+94doB1 4uyNdy3fvoprtYzLoEHjyDyBZK9SLV5u8xyHToSEAGFPmQntLKUtYvHNvr27hYYQtpx9 HHdtwKkodIWQiYWCyQhD0X6tohmKQJKZgYpVHkXHXof6QIPERQxadL9RHHcZj0Cc6kOu 1itASmdACmvbc8yo6sqjRgHXl2z7NUB6a/lEevsnGCfgGa9LfiqPcUn6nn3Nt7cu5RJR 1Ryw== X-Forwarded-Encrypted: i=1; AJvYcCWMXDI13pNmpIYVH6ybnrHHOEdK4EdV2tJs65fj6ko0tOhbhrie+/o5c/qLCNTjIOlcYmvk+thBd4MXyBU=@vger.kernel.org X-Gm-Message-State: AOJu0YzIOqxEZUDUi6du+r9+4Qbbqlf9QGNl+EPJljdBZdvPtyvr+DOh 77fkul6yKMo0Rr/YLizKcBuSvHmLRKNVZ4pPJI5LjOahSaUpUfkH4pUIjl96v7zXXqAMKjuYnBC YZsd09nQ= X-Gm-Gg: ATEYQzwkIPQTxzeFgZ6ujw71/L9pLRCqhwwVRcnqCgU21kU2qM2KaXwwZ94nnaKBQQY nrMfG+caxGXtQkyujqMKsuRHXIAgqnQCFOXvfLA/z9ZeR7kj8shSql2rzsXN/fTS+I+dG6OI7fd zWgZXzMwIX7vRmTiWAFj5nyeVHhXlJphq02GlI1y5YAsewTExzGeanF9hLyqPd4y34GDvQm0aAR oBbzsY+xpohcsyDptAiD2aT61Ip8V6S0U0eluJmc9AaO0LKlYmKePN489tAE3XI1uXfGOSQzHK6 8XSyq1BW91E1/MzY9gizweTJeoneds71FSyUdeiBuZOlxW1WWQBkt602U2V+c5vuJPaapZWQLTZ mxODutXyEG4SxP1sFFRQXugEOHDde8IhIP31oiK05VJN1rxAw1oQO7z69QG5jlrM9zvXk2/Abep Bve74y1rdyI2imFN03HsnlzTh22LIL9132souNry+93GcUZ0DALA== X-Received: by 2002:a05:620a:4146:b0:8cd:827a:2abb with SMTP id af79cd13be357-8cd827a371dmr585176385a.31.1773061893070; Mon, 09 Mar 2026 06:11:33 -0700 (PDT) Received: from [172.19.0.48] ([99.196.133.212]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cd8d4cac0esm136699885a.36.2026.03.09.06.11.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 06:11:31 -0700 (PDT) Message-ID: <959a75c9-4de5-42d1-8f43-636f4aab5df8@kernel.dk> Date: Mon, 9 Mar 2026 07:11:21 -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 To: Hao-Yu Yang , security@kernel.org Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260309062759.482210-1-naup96721@gmail.com> Content-Language: en-US From: Jens Axboe In-Reply-To: <20260309062759.482210-1-naup96721@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/9/26 12:27 AM, Hao-Yu Yang wrote: > During io_register_resize_rings execution, ctx->rings is temporarily > set to NULL before new ring memory is allocated. If a timer interrupt > fires during this window, the interrupt handler (via timerfd_tmrproc > -> io_poll_wake -> __io_req_task_work_add -> io_req_local_work_add) > attempts to access ctx->rings->sq_flags, causing race condition and > a NULL pointer dereference. > > BUG: kernel NULL pointer dereference, address: 0000000000000024 > PF: supervisor read access in kernel mode > PF: error_code(0x0000) - not-present page > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 > Call Trace: > > __io_poll_execute (io_uring/poll.c:223) > io_poll_wake (io_uring/poll.c:426) > __wake_up_common (kernel/sched/wait.c:109) > __wake_up_locked_key (kernel/sched/wait.c:167) > timerfd_tmrproc (./include/linux/spinlock.h:407 fs/timerfd.c:71 fs/timerfd.c:78) > ? __pfx_timerfd_tmrproc (fs/timerfd.c:75) > __hrtimer_run_queues (kernel/time/hrtimer.c:1785 kernel/time/hrtimer.c:1849) > hrtimer_interrupt (kernel/time/hrtimer.c:1914) > __sysvec_apic_timer_interrupt (./arch/x86/include/asm/jump_label.h:37 ./arch/x86/include/asm/trace/irq_vectors.h:40 arch/x86/kernel/apic/apic.c:1063) > sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1056 arch/x86/kernel/apic/apic.c:1056) > > > asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:697) > RIP: 0010:io_register_resize_rings (io_uring/register.c:593) > ? io_register_resize_rings (io_uring/register.c:580) > __io_uring_register (io_uring/register.c:898) > ? fget (fs/file.c:1114) > __x64_sys_io_uring_register (io_uring/register.c:1026 io_uring/register.c:1001 io_uring/register.c:1001) > x64_sys_call (arch/x86/entry/syscall_64.c:41) > do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall) > entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) > > > Fix by using spin_lock_irq/spin_unlock_irq instead of spin_lock/spin_unlock > in io_register_resize_rings. This disables IRQs while ctx->rings is set to > NULL, preventing interrupt handlers from executing during the window when > ctx->rings is NULL. I see the your crash, but this isn't the right fix - you can't just have that one spot turn the completion lock into an IRQ disabling one, that'll mess up the rest of the use cases in terms of lockdep. This lock is never grabbed from IRQ context, hence it'd be misleading too. You probably want something ala: mutex_lock(&ctx->mmap_lock); spin_lock(&ctx->completion_lock(); + local_irq_disable(); ... + local_irq_enable(); spin_unlock(&ctx->completion_lock); mutex_unlock(&ctx->mmap_lock); which I think should make lockdep happy with it too. And then I think it wants a comment on top of that local_irq_disable(), explaining how this is meant to prevent any irq/bh from triggering task_work additions that touch ctx->rings to set the IORING_SQ_TASKRUN flag. Does that makes sense? If so, please do send a v2! -- Jens Axboe