From: cel@kernel.org
To: Neil Brown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>,
Rick Macklem <rick.macklem@gmail.com>,
j.david.lists@gmail.com, Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH v3 0/6] Fix XDR encoding near page boundaries
Date: Thu, 26 Dec 2024 11:28:47 -0500 [thread overview]
Message-ID: <20241226162853.8940-1-cel@kernel.org> (raw)
From: Chuck Lever <chuck.lever@oracle.com>
Refresh the patch series to address the longstanding bug pointed out
by J David and Rick Macklem.
I believe we have identified and addressed this issue in all of
the NFSv4 COMPOUND operation encoders on the server side. Only the
GSS integrity and privacy encoders are still vulnerable but "safe
for now". Barring further review comments, this series is code-
complete.
Neil suggests xdr_reserve_space() should not ever be open-coded in
NFSv4 code. That seems difficult to enforce: nfsd4_encode_operation()
is certainly an XDR encode function; it lives in fs/nfsd/nfs4xdr.c,
for instance. So xdr_reserve_space() seems like a reasonable thing
to see in that function. I'm not sure exactly where to draw that
line.
Changes since v2:
- Address same issue in NFSv4 READ/READ_PLUS and fattr4 encoders
Chuck Lever (6):
NFSD: Encode COMPOUND operation status on page boundaries
NFSD: Insulate nfsd4_encode_read() from page boundaries in the encode
buffer
NFSD: Insulate nfsd4_encode_read_plus() from page boundaries in the
encode buffer
NFSD: Insulate nfsd4_encode_read_plus_data() from page boundaries in
the encode buffer
NFSD: Insulate nfsd4_encode_fattr4() from page boundaries in the
encode buffer
SUNRPC: Document validity guarantees of the pointer returned by
reserve_space
fs/nfsd/nfs4xdr.c | 109 ++++++++++++++++++++++++++--------------------
net/sunrpc/xdr.c | 3 ++
2 files changed, 65 insertions(+), 47 deletions(-)
--
2.47.0
next reply other threads:[~2024-12-26 16:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-26 16:28 cel [this message]
2024-12-26 16:28 ` [PATCH v3 1/6] NFSD: Encode COMPOUND operation status on page boundaries cel
2024-12-26 17:17 ` Cedric Blancher
2024-12-27 2:06 ` Chuck Lever
2024-12-26 16:28 ` [PATCH v3 2/6] NFSD: Insulate nfsd4_encode_read() from page boundaries in the encode buffer cel
2024-12-26 16:28 ` [PATCH v3 3/6] NFSD: Insulate nfsd4_encode_read_plus() " cel
2024-12-26 16:28 ` [PATCH v3 4/6] NFSD: Insulate nfsd4_encode_read_plus_data() " cel
2024-12-26 16:28 ` [PATCH v3 5/6] NFSD: Insulate nfsd4_encode_fattr4() " cel
2024-12-26 16:28 ` [PATCH v3 6/6] SUNRPC: Document validity guarantees of the pointer returned by reserve_space cel
2024-12-26 22:36 ` NeilBrown
2024-12-27 0:52 ` 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=20241226162853.8940-1-cel@kernel.org \
--to=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=j.david.lists@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=rick.macklem@gmail.com \
--cc=tom@talpey.com \
/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