nfs4_block_decode_volume() in fs/nfs/blocklayout/dev.c decodes stripe
parameters from GETDEVICEINFO XDR without checking for zero values.
A malicious pNFS server returning chunk_size=0 causes a division-by-
zero panic in bl_map_stripe() via div_u64(offset, dev->chunk_size).
Separately, volumes_count=0 passes the existing upper-bound check
and causes a second division-by-zero via div_u64_rem(chunk,
dev->nr_children=0).

Impact: a malicious or compromised pNFS blocklayout server can panic an
affected Linux NFS client after the client mounts/uses the server and maps
I/O through the poisoned blocklayout. An in-kernel parser/mapper KUnit
reproducer is available privately.

Reject both zero values at decode time with -EIO.

Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
 fs/nfs/blocklayout/dev.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/blocklayout/dev.c b/fs/nfs/blocklayout/dev.c
index cc6327d97a91a..fc60669db3ec4 100644
--- a/fs/nfs/blocklayout/dev.c
+++ b/fs/nfs/blocklayout/dev.c
@@ -183,8 +183,11 @@ nfs4_block_decode_volume(struct xdr_stream *xdr, struct pnfs_block_volume *b)
 			return -EIO;
 
 		p = xdr_decode_hyper(p, &b->stripe.chunk_size);
+		if (!b->stripe.chunk_size)
+			return -EIO;
 		b->stripe.volumes_count = be32_to_cpup(p++);
-		if (b->stripe.volumes_count > PNFS_BLOCK_MAX_DEVICES) {
+		if (!b->stripe.volumes_count ||
+		    b->stripe.volumes_count > PNFS_BLOCK_MAX_DEVICES) {
 			dprintk("Too many volumes: %d\n", b->stripe.volumes_count);
 			return -EIO;
 		}
-- 
2.53.0

On Sat, 2026-07-11 at 11:05 -0400, Michael Bommarito wrote:
> nfs4_block_decode_volume() in fs/nfs/blocklayout/dev.c decodes stripe
> parameters from GETDEVICEINFO XDR without checking for zero values.
> A malicious pNFS server returning chunk_size=0 causes a division-by-
> zero panic in bl_map_stripe() via div_u64(offset, dev->chunk_size).
> Separately, volumes_count=0 passes the existing upper-bound check
> and causes a second division-by-zero via div_u64_rem(chunk,
> dev->nr_children=0).
> 
> Impact: a malicious or compromised pNFS blocklayout server can panic
> an
> affected Linux NFS client after the client mounts/uses the server and
> maps
> I/O through the poisoned blocklayout. An in-kernel parser/mapper
> KUnit
> reproducer is available privately.
> 
> Reject both zero values at decode time with -EIO.
> 
> Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR
> parsing")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
>  fs/nfs/blocklayout/dev.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/nfs/blocklayout/dev.c b/fs/nfs/blocklayout/dev.c
> index cc6327d97a91a..fc60669db3ec4 100644
> --- a/fs/nfs/blocklayout/dev.c
> +++ b/fs/nfs/blocklayout/dev.c
> @@ -183,8 +183,11 @@ nfs4_block_decode_volume(struct xdr_stream *xdr,
> struct pnfs_block_volume *b)
>  			return -EIO;
>  
>  		p = xdr_decode_hyper(p, &b->stripe.chunk_size);
> +		if (!b->stripe.chunk_size)
> +			return -EIO;
>  		b->stripe.volumes_count = be32_to_cpup(p++);
> -		if (b->stripe.volumes_count >
> PNFS_BLOCK_MAX_DEVICES) {
> +		if (!b->stripe.volumes_count ||
> +		    b->stripe.volumes_count >
> PNFS_BLOCK_MAX_DEVICES) {
>  			dprintk("Too many volumes: %d\n", b-
> >stripe.volumes_count);
>  			return -EIO;
>  		}

NACK to this, and all further patches with the words "malicious server"
as their justification. It's time to stop this incessant flood of
worthless AI slop...

This is storage, not grandma's email server. If you have a "malicious
server" then it's game over. Your attempts to detect 0 length fields is
going to be pointless security theatre because a real malicious actor
will just corrupt the data.
If a server is sending this kind of thing due to a bug, then you
shouldn't trust it with your data. Just find a server that follows the
spec.

So no, we're not going to waste more time on this kind of junk
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

On Tue, Jul 14, 2026 at 10:37 AM Trond Myklebust <trondmy@kernel.org> wrote:
> NACK to this, and all further patches with the words "malicious server"
> as their justification. It's time to stop this incessant flood of
> worthless AI slop...

Sure, I hear you.  I'll make a note to skip your subsystem going forward.

FWIW though, these are often exacty the networks where ARP spoofing
still works and malicious server can be read to mean "anyone who can
pretend to be a server/peer" for the relevant packet/session.

Thanks,
Mike

On Tue, 2026-07-14 at 10:41 -0400, Michael Bommarito wrote:
> On Tue, Jul 14, 2026 at 10:37 AM Trond Myklebust <trondmy@kernel.org>
> wrote:
> > NACK to this, and all further patches with the words "malicious
> > server"
> > as their justification. It's time to stop this incessant flood of
> > worthless AI slop...
> 
> Sure, I hear you.  I'll make a note to skip your subsystem going
> forward.
> 
> FWIW though, these are often exacty the networks where ARP spoofing
> still works and malicious server can be read to mean "anyone who can
> pretend to be a server/peer" for the relevant packet/session.
> 
> Thanks,
> Mike

Then seeing this is a great opportunity to discover that you have an
insecure network, and that you should have been using either krb5i,
krb5p, TLS or secure VLAN technology to protect your on-the-wire
message protocols against precisely this kind of man-in-the-middle
attack.

Again, though, a savvy man-in-the-middle won't be trying to cause
clients to crash when they have a golden opportunity to manipulate the
stored data instead.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com