From: Hiroyuki Sato <hiroysato@gmail.com>
To: nfs <linux-nfs@vger.kernel.org>
Subject: [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff)
Date: Sun, 5 Apr 2026 13:17:11 +0900 [thread overview]
Message-ID: <CA+Tq-RqDP_BAroLX6wVrNY1BMwC9BOZ-UorLje=TXBdEOj8hjQ@mail.gmail.com> (raw)
Hello,
1. Observed behavior
* When sending a COMPOUND request with the tag "create_session" (14 bytes),
the reply is expected to include XDR padding to a 4-byte boundary,
i.e. "create_session" + "\x00\x00".
* On 5.14.0-611.45.1.el9_7.x86_64 (AlmaLinux 9), the padding bytes
are sometimes observed to be non-zero (e.g. "\xff\xff").
* From inspection of recent upstream code, nfs4svc_encode_compoundres()
also appears not to explicitly zero-fill the padding.
2. Questions
* Is this understanding correct?
* If so, is this a known issue or something that should be fixed?
3. Analysis
* In nfsd4_proc_compound(), space for taglen + tag + opcnt is reserved via:
xdr_reserve_space(resp->xdr, XDR_UNIT * 2 + args->taglen);
* In nfs4svc_encode_compoundres(), only the tag payload is copied:
memcpy(p, resp->tag, resp->taglen);
* The pointer is then advanced using: p += XDR_QUADLEN(resp->taglen);
* but the padding bytes do not appear to be explicitly zeroed.
* As a result, it seems possible that uninitialized data remains in
the padding region, which may explain why non-zero values
such as \xff\xff appear on the wire.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/nfsd/nfs4proc.c#n3055
```C
/*
* COMPOUND call.
*/
static __be32
nfsd4_proc_compound(struct svc_rqst *rqstp)
{
// snip
/* reserve space for: taglen, tag, and opcnt */
xdr_reserve_space(resp->xdr, XDR_UNIT * 2 + args->taglen);
```
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/nfsd/nfs4xdr.c#n6389
```C
bool
nfs4svc_encode_compoundres(struct svc_rqst *rqstp, struct xdr_stream *xdr)
{
// snip
memcpy(p, resp->tag, resp->taglen);
p += XDR_QUADLEN(resp->taglen);
```
4. Additional observations
* A packet capture excerpt (attached separately via gist) shows:
(https://gist.github.com/hiroyuki-sato/8ab30dffbbd2499e8b4741d89fd383be)
* The issue is not deterministic: when repeatedly sending CREATE_SESSION,
it was observed roughly once every ~5 attempts.
* This was discovered while implementing an NFSv4 client in Rust.
Best regards,
--
Hiroyuki Sato
next reply other threads:[~2026-04-05 4:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 4:17 Hiroyuki Sato [this message]
2026-04-06 4:22 ` [Q] NFSD: COMPOUND reply tag padding not zeroed? (e.g. \xff\xff) Hiroyuki Sato
2026-04-06 13:15 ` Chuck Lever
2026-04-07 5:23 ` Hiroyuki Sato
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='CA+Tq-RqDP_BAroLX6wVrNY1BMwC9BOZ-UorLje=TXBdEOj8hjQ@mail.gmail.com' \
--to=hiroysato@gmail.com \
--cc=linux-nfs@vger.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).