From: Chuck Lever <cel@kernel.org>
To: Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Scott Mayhew <smayhew@redhat.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org,
Farhad Alemi <farhad.alemi@berkeley.edu>,
Chuck Lever <cel@kernel.org>
Subject: [PATCH 0/5] Fix premature completion of rpc_pipefs upcalls
Date: Sun, 30 Aug 2026 20:38:37 -0400 [thread overview]
Message-ID: <20260830-alemi-v1-0-463f80b9e9a8@kernel.org> (raw)
Farhad Alemi's syzkaller run against 7.1-rc5 hit a KASAN
vmalloc-out-of-bounds in rpc_queue_upcall() while NFSD was starting
client tracking:
https://lore.kernel.org/linux-nfs/CA+0ovCjVF58WLeen2ctdzHyWUASAAW3Y=Yjihyq0pFApYawtDg@mail.gmail.com/
The cld downcall matches a reply to its upcall by xid alone. If a
write arrives before nfsdcld has read the upcall, the waiter returns
while its struct rpc_pipe_msg is still queued, and the pipe is left
holding a list_head into a dead stack frame. The blocklayout device
upcall has the same bug, plus two of its own: the waiter can go to
sleep after the reply has arrived, and a reply left over from a
purged upcall is taken as a fresh one.
rpc_pipefs pipes are mode 0600, so the writer is a daemon running as
root. These patches guard against a broken or hostile daemon, which
is unlikely. So consider the series as hardening rather than urgent.
The gss and idmap consumers keep their message in an object that
lives as long as the upcall and do not have this problem. The cld
and blocklayout fixes also complete only once the daemon has
consumed the whole message, and keep the message somewhere that
outlives the waiter.
Reading cld_pipe_downcall() for the fix turned up two unrelated
problems. A faulting reply copy strands the waiter and hangs NFSD
shutdown behind it, and an unchecked principal hash length reads past
a stack array in nfsd4_cld_check_v2().
Farhad, a run of your reproducer against this series would help.
---
Chuck Lever (5):
NFSD: Don't complete a cld upcall the daemon has not read
NFSD: Move the cld upcall message out of the caller's stack frame
NFSD: Complete a cld upcall when copying its reply fails
NFSD: Reject an oversized principal hash from nfsdcld
pnfs/blocklayout: Complete a device upcall only on its own reply
fs/nfs/blocklayout/blocklayout.h | 5 ----
fs/nfs/blocklayout/rpc_pipefs.c | 56 +++++++++++++++++++++++++---------------
fs/nfs/netns.h | 5 +++-
fs/nfsd/nfs4recover.c | 53 +++++++++++++++++++++++++++----------
4 files changed, 78 insertions(+), 41 deletions(-)
---
base-commit: e3c3b1a8188b192b125ae1fc9861d9a5d8d43d85
change-id: 20260830-alemi-d9f420956e8d
Best regards,
--
Chuck Lever
next reply other threads:[~2026-08-31 0:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 0:38 Chuck Lever [this message]
2026-08-31 0:38 ` [PATCH 1/5] NFSD: Don't complete a cld upcall the daemon has not read Chuck Lever
2026-08-31 0:38 ` [PATCH 2/5] NFSD: Move the cld upcall message out of the caller's stack frame Chuck Lever
2026-08-31 0:38 ` [PATCH 3/5] NFSD: Complete a cld upcall when copying its reply fails Chuck Lever
2026-08-31 0:38 ` [PATCH 4/5] NFSD: Reject an oversized principal hash from nfsdcld Chuck Lever
2026-08-31 0:38 ` [PATCH 5/5] pnfs/blocklayout: Complete a device upcall only on its own reply Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830-alemi-v1-0-463f80b9e9a8@kernel.org \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=bfields@fieldses.org \
--cc=farhad.alemi@berkeley.edu \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=smayhew@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox