linux-kernel - Re: [PATCH 2/3] sys_personality: make sure (int)personality >= 0

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:	Thu, 27 May 2010 13:02:51 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 2/3] sys_personality: make sure (int)personality >= 0

On 05/27/2010 08:36 AM, Oleg Nesterov wrote:
> Not sure about this patch. The kernel/libc part is correct, but
> since user-space declares "int personality(unsigned long persona)"
> the current behaviour can confuse the (poor written) applications
> even on 64-bit machines.
> 
> Consider:
> 
> 	personality(0xffffffff - 1);	// == (int)-2
> 
> 	...
> 
> 	int ret = personality(0);	// returns the old personality
> 	if (ret < 0)
> 		oops_we_cant_set_PER_LINUX(errno);
> 
> And, since libc correctly detects the successful return from syscall,
> errno is random.
> 
> Change sys_personality() to ensure personality can not look like a
> negative int. This disallows the MSB, it is not used for PER_ flags.
> 
> Suggested-by: Wenming Zhang <wezhang@...hat.com>
> Signed-off-by: Oleg Nesterov <oleg@...hat.com>

I'm fine with this, even though it is indeed there to support extremely
poorly written applications (error is specifially -1, not < 0).

However, since we almost certainly have enough brokenness in here, and
since there definitely don't seem to be a whole lot of demand for new
personality bits, I'm more than happy to waste bit 31 at not having to
deal with it, ever.

However, it would be better if we returned -EINVAL on attempts to set
*any* of the reserved bits, not just bit 31.

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