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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a6d1435b-f507-49eb-b80c-4322dc7e1157@oracle.com>
Date: Fri, 14 Nov 2025 09:18:34 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: "Tyler W. Ross" <TWR@...erwross.com>
Cc: Salvatore Bonaccorso <carnil@...ian.org>,
        "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>,
        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 11/14/25 12:09 AM, Tyler W. Ross wrote:
> On Thursday, November 13th, 2025 at 9:35 PM, Tyler W. Ross <TWR@...erwross.com> wrote:
> 
>> I tried a couple vanilla/stock kernels today, without success.
>>
>> Most notably, I built 6.17.8 from upstream using the Kconfig from the
>> working Fedora 43 client in my lab ("config-6.17.5-300.fc43.x86_64").
>>
>> Unfortunately, the rpc_xdr_overflow still occurs with this kernel.
> 
> Quick addendum:
> 
> I had not tried Debian 12, because CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2
> was not enabled in the shipped Kconfig.
> 
> I just spun up a Debian 12 VM and installed the aforementioned
> upstream 6.17.8 with Fedora 43 Kconfig kernel and confirmed the issue
> also occurs on Debian 12.
Then I would say further hunting for the broken commit is going to be
fruitless. Adding the WARNs in net/sunrpc/xdr.c is a good next step so
we see which XDR data item (assuming it's the same one every time) is
failing to decode.


-- 
Chuck Lever

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ