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 6EEBC31355D; Fri, 8 May 2026 20:47:23 +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=1778273243; cv=none; b=EvoCj3M+F0J+LOzdiHtt6+11NW5gmGnj9XEnp4SPz/z5px57IoncLMEa3UpeUYDueR4eqDJDhY4M+uOCKv5wBmOpiY+EzMGxrWMVv0z4p+iU5jFybLHv0eY4uJEfVpCRculFXMx/577lOO6ZdxcYYrFkHPqYTqLnxmjQ6/+7q2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778273243; c=relaxed/simple; bh=04eERtcYZTyoE47VoMdJU6HTayMdgVwWdiPoUM+EL4U=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=D74xaFJwY3VLY27rqz+oL0tzcGKGtfdyISNpr04Fh4DhibfPW5ooo0WtaroA+WDhQ42ZsHL9QM62TIS9vfZDi/96zMtPKjoqVTWll6iJXq+RIVZg/MuLxTZzTNsf91VVTUJBxTGfge17gm/pBcB5u+CqC0eP8/4duOpka3yjzV4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mJBj/nls; 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="mJBj/nls" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D9D9C4AF09; Fri, 8 May 2026 20:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778273243; bh=04eERtcYZTyoE47VoMdJU6HTayMdgVwWdiPoUM+EL4U=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=mJBj/nls3ManCWyQSlhPYwmdaLHRMLeWkqnGFTnPAG2rpztneFvOtCIaEfU5OoiR8 lms+cgRAHF0Lej0hss+pXS4iPi9y0Rwp/ClCEHVxhDSe7htjQ0RoQCQFNBFtNkTouK z7HVoUOzyP3yDgI3WsfkkMvQNN1BWun/oVAEOnWD+sjD96iBnpBFN07vuCklmAEA/F 9lvA89N+6yhUp27Vbx/2zFmMY6Hpu5t2JdyHXCvQtcqXIxkaHLk5lIDHMfUYOqAg73 DjAzcXXjBfFLFbaHNq8Y8Fx5Wz6loQE8QBHbOMi1lDf9lje5IaNU4q3fPuLyiVMkEh jckyGcA4v/SBw== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id B4EDDF40068; Fri, 8 May 2026 16:47:21 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Fri, 08 May 2026 16:47:21 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduuddufeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedfvehhuhgt khcunfgvvhgvrhdfuceotggvlheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpefghfeguedtieeiveeugfevtdejfedukeevgfeggfeugfetgfeltdetueelleelteen 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 8A2B5780070; Fri, 8 May 2026 16:47:21 -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: Fri, 08 May 2026 16:47:00 -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: In-Reply-To: <39819ad4-3105-4802-b5e2-79e131b25984@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> Subject: Re: [PATCH 0/6] SUNRPC: Address remaining cache_check_rcu() UAF in cache content files Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Erkun - On Fri, May 8, 2026, at 9:00 AM, yangerkun wrote: > =E5=9C=A8 2026/5/8 16:16, yangerkun =E5=86=99=E9=81=93: >>=20 >>=20 >> =E5=9C=A8 2026/5/8 11:08, yangerkun =E5=86=99=E9=81=93: >> After reviewing these two commits: >>=20 >> e7fcf179b82d NFSD: Hold net reference for the lifetime of /proc/fs/nf= s/=20 >> exports fd >> 48db892356d6 NFSD: Defer sub-object cleanup in export put callbacks >>=20 >> I believe that the issue described in commit e7fcf179b82d might be the >> root cause of the null pointer dereferences mentioned in [1]. That's where I landed too. e7fcf179b82d closed the specific oops Misbah hit on /proc/fs/nfs/exports. The matching patch in this series is 5/6 ("SUNRPC: Hold cd->net for the lifetime of cache files"), which extends the same get_net()/put_net() guard to the sunrpc cache files at /proc/net/rpc//{content,channel,flush} . Those open helpers had the same hole; sosreport just hit the nfsd-specific file first because it reads /proc/fs/nfsd/exports. Patch 5/6's changelog pins down the deref site you asked about: cache_check_rcu() faults reading h->flags off a garbage cache_head returned by __cache_seq_start() walking a cd->hash_table that cache_destroy_net() already freed. Not a dentry deref. The dentry-teardown path is a separate failure mode that 48db892356d6 closed for the export and expkey caches. >> To prevent the >> issue described in commit 69d803c40ede, should we consider reverting >> commit 48db892356d6 first? Not for this series. Patches 3/6 and 4/6 don't add any new path_put deferral; their commit messages call them out as consistency changes, not bug fixes. ip_map holds only an auth_domain reference and unix_gid holds only a group_info, so neither cache reaches mntput from the deferred release. The exportfs-r-then-umount sequence isn't touched by this series. The svc_export and svc_expkey path_put deferral lives in 48db892356d6, which is already in v7.0. If the umount window from 69d803c40ede is still reachable through that commit, that's a regression in 48db892356d6 and worth a separate thread. > Locally, I wrote a stable regression test case. I also reverted to=20 > commit 9189d23b835cec646ba5010db35d1557a77c5857 (which is before commi= ts=20 > 2862eee078a4 "SUNRPC: make sure cache entry active before cache_show"=20 > and be8f982c369c "nfsd: make sure exp active before svc_export_show").=20 > Even then, a panic can still be triggered without any actual export pa= th... That fits 5/6's failure mode. Without an export no svc_export or svc_expkey entry is populated, but rpc.mountd reads auth.unix.ip/content and auth.unix.gid/content directly, and on a pre-5/6 tree the open helpers in cache.c hold no reference on cd->net. cache_destroy_net() at namespace exit then races a reader still inside cache_seq_start_rcu(), and the reader walks a freed cd->hash_table. = = =20 Could you share the reproducer and the panic stack trace? If the fault is in cache_check_rcu() through one of the sunrpc cache files, that confirms 5/6 is the right fix, and I'll happily carry your Tested-by on it. --=20 Chuck Lever