From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80CF426CE32; Sun, 10 May 2026 16:18:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778429922; cv=none; b=nqw2bfzUUnTg9tXFbVlRp9HRQTgu7Q4D++do79gmCu8WikDALJgMtkUTX16j78L1NiMbG4ZYHBSRJ78YpIUehqAF00H62j52xaGSc7yyZEMTNb2pUIc8naJwkAMJp7nfVJ32Nnj9e9/ARP7Q7D/uxGFVHpXC2dYjmRymj775LpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778429922; c=relaxed/simple; bh=jaJiobhqmBEatYVZgeUjteznE9wyQENeyYC4HU+GyGU=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=UCQrNHvYbR/TABRhObVnIi98wC7wFDVJukI78jN8JyI+L5XS0Fch+tQK0Mj0b4EGUlkZK8p70Vdy6+YLUDpXqltgnA6v5x1JMOwsAdgAG/THBndnhXqhm/ULP8ja4O6kdxsG4BwbnHKOfqFhH9n5CArLIzxhEdpxAotq8/CNdNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EZm4KVRX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EZm4KVRX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE905C2BCB8; Sun, 10 May 2026 16:18:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778429922; bh=jaJiobhqmBEatYVZgeUjteznE9wyQENeyYC4HU+GyGU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=EZm4KVRXkoccaP+Ymy4ZtKqUKWkFnzD30i2DcTSqr1BGvmaShmmkfqbRrnWXZTmI9 e9W2jJRT0YcfRsm6JJXFWknAKLUjUAI9KLbVsrETyg7sJF0a1Gkzj5jfDEFgIWTFOs bBi0OTjttzKqBgOYSYHV+CZPlyMvJrjrMv+11QqY8AYCTwS02XGJm5U6NbLg1pnPDR 2lqqV2X8QtdtKKAnswBZvMGTXjoJjGruwjleqCP7hj6jaakFupc1I/jxpU7N4LwE8U 35eIV5gTFJQue7va0CdhZrFLxGvYPzXnP0QkRi/XzRBKrT+8/78H6XpS0XqK4V7gAi Cse3T7oHTkfhg== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id BA4AEF4006E; Sun, 10 May 2026 12:18:40 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Sun, 10 May 2026 12:18:40 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduudeiheeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfvehhuhgt khcunfgvvhgvrhdfuceotggvlheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpefhffekffeftdfgheeiveekudeuhfdvjedvfedvueduvdegleekgeetgfduhfefleen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegthhhutg hklhgvvhgvrhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeifeegleel leehledqfedvleekgeegvdefqdgtvghlpeepkhgvrhhnvghlrdhorhhgsehfrghsthhmrg hilhdrtghomhdpnhgspghrtghpthhtohepvddupdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehnvghilhessghrohifnhdrnhgrmhgvpdhrtghpthhtohepuggrvhgvmhesug grvhgvmhhlohhfthdrnhgvthdprhgtphhtthhopegvughumhgriigvthesghhoohhglhgv rdgtohhmpdhrtghpthhtoheptghhvghnghiihhhihhgrohdusehhuhgrfigvihdrtghomh dprhgtphhtthhopehlihhlihhnghhfvghnghefsehhuhgrfigvihdrtghomhdprhgtphht thhopeihrghnghgvrhhkuhhnsehhuhgrfigvihdrtghomhdprhgtphhtthhopeihihdrii hhrghngheshhhurgifvghirdgtohhmpdhrtghpthhtoheprghnnhgrsehkvghrnhgvlhdr ohhrghdprhgtphhtthhopehhohhrmhhssehkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: ifa6e4810:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 8B621780070; Sun, 10 May 2026 12:18:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AxcNF55tVgJk Date: Sun, 10 May 2026 12:18:20 -0400 From: "Chuck Lever" To: yangerkun , "Misbah Anjum N" , "Jeff Layton" , NeilBrown , "Olga Kornievskaia" , "Dai Ngo" , "Tom Talpey" , "Trond Myklebust" , "Anna Schumaker" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Simon Horman" , yi.zhang@huawei.com, "Zhihao Cheng" , "Li Lingfeng" Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, "Chuck Lever" Message-Id: <98268bb4-2e97-4728-96a6-37b2a4a3ae5d@app.fastmail.com> In-Reply-To: <4ee398d0-d2ec-45b2-8214-6e35520fca2d@huawei.com> References: <20260501-cache-uaf-fix-v1-0-a49928bf4817@oracle.com> <76a10e49-54a6-4813-8b58-b7cd0820fdc6@app.fastmail.com> <4bb9ed6b-1a64-406a-9239-b0560ca963cc@huawei.com> <05f93fc4-59d7-4735-bc7d-a00d1497687a@huawei.com> <10019b42-4589-4f9f-8d5b-d8197db1ce3c@huawei.com> <39819ad4-3105-4802-b5e2-79e131b25984@huawei.com> <4ee398d0-d2ec-45b2-8214-6e35520fca2d@huawei.com> Subject: Re: [PATCH 0/6] SUNRPC: Address remaining cache_check_rcu() UAF in cache content files Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Erkun - On Sat, May 9, 2026, at 5:41 AM, yangerkun wrote: > Hmm... /proc/net is always a symlink to /proc/self/net. After opening > /proc/net/rpc//content and attempting to read it, the > proc_reg_read function calls use_pde before pde_read. This sequence can > prevent a race condition because nfsd_export_shutdown leads to > cache_unregister_net, which calls remove_cache_proc_entries, then > proc_remove, and eventually proc_entry_rundown. The proc_entry_rundown > function waits until unuse_pde is called in proc_reg_read. Therefore, > I'm not sure if forgetting to call get_net when opening > /proc/net/rpc//content is the root cause of the null pointer in > c_show. Walked the synchronization. You're right. cache_unregister_net() calls remove_cache_proc_entries(), which runs proc_remove(); remove_proc_subtree() then invokes proc_entry_rundown() on each per-cache file. Rundown does atomic_add_return(BIAS, &de->in_use), where BIAS = -1U << 31. No active readers means the post-add value equals BIAS and rundown returns at once. Readers present means the value exceeds BIAS, and wait_for_completion() blocks until the last unuse_pde() decrements the counter to exactly BIAS and signals the completion. atomic_inc_unless_negative() in use_pde() then fails, so any later read() on a still-open userspace fd returns -EIO without touching cd. close_pdeo() forces release on the remaining openers while cd is still valid. cache_destroy_net() runs only after that whole sequence has finished, so cd->hash_table is freed once no reader can be inside cache_seq_*_rcu() and no fd can dereference cd through a release callback. The 5/6 changelog overstates the window. Your reproducer opens /proc/fs/nfs/exports through exports_nfsd_open(), which bypasses use_pde() and is the path e7fcf179b82d closed. The sunrpc cache files reach c_show through proc_reg_read(), which goes through use_pde()/unuse_pde() and is covered by rundown. 5/6 doesn't close the hazard its changelog describes. Patch 3/6 is what matches Misbah's reproducer. Pre-series ip_map_put() drops auth_domain_put() synchronously, with only the ip_map free deferred: auth_domain_put(&im->m_client->h); /* synchronous */ kfree_rcu(im, m_rcu); A reader walking auth.unix.ip/content under rcu_read_lock() can dereference im->m_client after the auth_domain has been freed. Same shape as 48db892356d6's svc_export fix, applied to ip_map. 3/6 moves auth_domain_put() into a deferred ip_map_release() scheduled via queue_rcu_work(), so the sub-object free waits for the grace period. For v2: re-test Misbah's reproducer with patches 1-4 and 6 only and see whether 3/6 alone closes the crash. If it does, drop 5/6; if it doesn't, reframe 5/6 as a consistency change without the UAF claim (and without the behavioral change that pins a netns alive while a debug fd is open). Either way, the cover letter needs a rewrite to match. Thanks for your analysis and review. -- Chuck Lever