linux-kernel - Re: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <N14GL1WKSGqrFl8nF0e6sa0QxOZrnrpoC7IZlZ20YqUyfsxpsoqu2W3a31H_GfQv7OEqaEWKwDXdgtAV-xv613w_slTAFZIoyWMutIE5pKk=@tylerwross.com>
Date: Thu, 13 Nov 2025 18:05:36 +0000
From: "Tyler W. Ross" <TWR@...erwross.com>
To: Chuck Lever <chuck.lever@...cle.com>
Cc: "1120598@...s.debian.org" <1120598@...s.debian.org>, Jeff Layton <jlayton@...nel.org>, NeilBrown <neil@...wn.name>, Scott Mayhew <smayhew@...hat.com>, Steve Dickson <steved@...hat.com>, Salvatore Bonaccorso <carnil@...ian.org>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, Trond Myklebust <trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>, linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2

On Thursday, November 13th, 2025 at 10:47 AM, Chuck Lever <chuck.lever@...cle.com> wrote:

> > ls-969 [003] ..... 270.327063: rpc_xdr_recvfrom: task:00000008@...00005 head=[0xffff8895c29fef64,140] page=4008(88) tail=[0xffff8895c29feff0,36] len=988
> > ls-969 [003] ..... 270.327067: rpc_xdr_overflow: task:00000008@...00005 nfsv4 READDIR requested=8 p=0xffff8895c29fefec end=0xffff8895c29feff0 xdr=[0xffff8895c29fef64,140]/4008/[0xffff8895c29feff0,36]/988
> 
> 
> Here's the problem. This is a sign of an XDR decoding issue. If you
> capture the traffic with Wireshark, does Wireshark indicate where the
> XDR is malformed?

Wireshark appears to decode the READDIR reply without issue. Nothing is obviously marked as malformed, and values all appear sane when spot-checking fields in the decoded packet.

TWR