linux-kernel - Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits

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: <20060820153037.GA20007@openwall.com>
Date:	Sun, 20 Aug 2006 19:30:37 +0400
From:	Solar Designer <solar@...nwall.com>
To:	Alex Riesen <fork0@...rs.sourceforge.net>,
	Willy Tarreau <wtarreau@...a.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits

On Sun, Aug 20, 2006 at 12:07:06PM +0200, Alex Riesen wrote:
> Solar Designer, Sun, Aug 20, 2006 02:38:40 +0200:
> > Attached is a trivial patch (extracted from 2.4.33-ow1) that makes
> > set*uid() kill the current process rather than proceed with -EAGAIN when
> > the kernel is running out of memory.  Apparently, alloc_uid() can't fail
> > and return anyway due to properties of the allocator, in which case the
> > patch does not change a thing.  But better safe than sorry.
> 
> Why not ENOMEM?

ENOMEM would not be any better than EAGAIN from the security standpoint.

The problem is that there are lots of privileged userspace programs that
do not bother to check the return value from set*uid() calls (or
otherwise check that the calls succeeded) before proceeding with work
that is only safe to do with the *uid switched as intended.

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