linux-kernel - Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Sep 2007 17:26:12 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	bfields@...ldses.org, neilb@...e.de, nfs@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [NFS] [BUG] 2.6.23-rc5 kernel BUG at fs/nfs/nfs4xdr.c:945

On Tue, 2007-09-25 at 00:31 +0530, Kamalesh Babulal wrote:
> > I'm mystified. I'm quite unable to reproduce this on my own setup: the
> > ENAMETOOLONG error reporting mechanism prevents me from even getting
> > near the above bug.
> > 
> > Could you add a little printk into the 'encode_lookup' routine on line
> > 944 of fs/nfs/nfs4xdr.c to display the value of 'len'?
> > 
> > Cheers
> >   Trond
> 
> Hi Trond,
> 
> Sorry, for replying so late, i have included the printk as you have requested.
> 
> len passed on encode_lookup [811]RESERVE_SPACE(819) failed in function encode_lookup

OK. That is definitely wrong! We shouldn't be allowing anything > 255
according to <limits.h>.

Looks like that code in fs/nfs/client.c has been wrong since its
inception in 2.6.18. Not only for NFSv4, but for NFSv2 and v3 too. We
only caught it 'cos v4 has more stringent tests...

Take two on the patch attached...

Trond

Download attachment "linux-2.6.23-002-fix_nfs4_namelen.dif" of type "message/rfc822" (4083 bytes)