linux-kernel - Re: NFS EINVAL on open(...

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: <20080206141636.1001b1c5.akpm@linux-foundation.org>
Date:	Wed, 6 Feb 2008 14:16:36 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Gianluca Alberici <gianluca@...networks.biz>
Cc:	chuck.lever@...cle.com, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9

On Wed, 06 Feb 2008 22:55:02 +0100
Gianluca Alberici <gianluca@...networks.biz> wrote:

> I finally got it. Problem and solution have been found from 6 month but 
> nobody cared...up to now those servers have not been mantained, this 
> problem is not discussed anywhere else than the following link.
> The bug (userspace server side i would say at this point) is well 
> described from the author of an nfs-user-server patch which has not been 
> managed yet. The magic hint to find it on google was 'nfs server 
> utimensat' :-)
> 
> http://marc.info/?l=linux-nfs&m=118724649406144&w=2

This is pretty significant.  We have on several occasions in recent years
tightened up the argument checking on long-standing system calls and it's
always a concern that this will break previously-working applications.

And now it has happened.

If we put buggy code into the kernel then we're largely stuck with it: we
need to be back-compatible with our bugs so we don't break things like
this.

> I have already prepared a working patch for cfsd based upon the one ive 
> listed. The nfs patch is of course waiting for commit since august, 
> 2007. Ill submit it to debian cfsd mantainers, hoping to have more 
> chance than my predecessor.
> It doesnt seem to me that there was any kernel related issue.
> 
> Thanks a lot again, sorry for the lots of noise i have done. I will try 
> to be more appropriate next time.

That wasn't noise - it was quite valuable.  Thanks for all the work you did
on this.

Given that our broken-by-unbreaking code has been out there in several
releases there isn't really any point in rebreaking it to fix this - the
offending applications need to be repaired so they'll work on 2.6.22 and
2.6.23 anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/