linux-kernel - Re: [PATCH 1/3] sys_personality: validate personality before set

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]

Message-ID: <alpine.LFD.2.00.1005271048590.3689@i5.linux-foundation.org>
Date:	Thu, 27 May 2010 10:51:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
cc:	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Richard Henderson <rth@...ddle.net>, wezhang@...hat.com,
	linux-kernel@...r.kernel.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	William Cohen <wcohen@...hat.com>
Subject: Re: [PATCH 1/3] sys_personality: validate personality before
 set_personality()

On Thu, 27 May 2010, Oleg Nesterov wrote:
> 
> But. Suppose an application does personality(0xffffffff << 32) on x86_64.
> 
> Before this patch we return -EINVAL (but wrongly change ->personality).
> After this patch this is equal to personality(0), right?

Yes. And I'm willing to take that "risk" in the name of not having to 
carry crazy stuff around in the kernel.

I don't think anybody does anything like that. At worst, they may have 
done sign-extension (due to lack of prototypes, whatever), and _wanted_ to 
do "personality(0xffffffff)" but instead ended up with the high bits set, 
and a non-working system call.

In which case the cleanup just helps such clueless cases. Not that I think 
those exist _either_, but whatever.

> If you think this is fine - I agree. In case we have a bug report we
> know who should be blamed ;)

Yup. I'll take the blame.

> You can also remove this "return -EINVAL", this is no longer possible.

I've already removed the patch from my tree, I wasn't going to commit it 
without somebody testing it. So maybe you could re-do the series with that 
cleanup too?

		Linus
--
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/