Linux NFS development
 help / color / mirror / Atom feed
* [PATCH 0/5] Fix premature completion of rpc_pipefs upcalls
@ 2026-08-31  0:38 Chuck Lever
  2026-08-31  0:38 ` [PATCH 1/5] NFSD: Don't complete a cld upcall the daemon has not read Chuck Lever
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Chuck Lever @ 2026-08-31  0:38 UTC (permalink / raw)
  To: Jeff Layton, NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
	J. Bruce Fields, Scott Mayhew, Trond Myklebust, Anna Schumaker
  Cc: linux-nfs, Farhad Alemi, Chuck Lever

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-08-31  0:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-31  0:38 [PATCH 0/5] Fix premature completion of rpc_pipefs upcalls Chuck Lever
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox