linux-kernel - Re: [PATCH] init: use KERNEL_DS when trying to start init process

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: <20110609155630.0f734351.akpm@linux-foundation.org>
Date:	Thu, 9 Jun 2011 15:56:30 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mathias Krause <minipli@...glemail.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	"David S. Miller" <davem@...emloft.net>,
	Chris Zankel <chris@...kel.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH] init: use KERNEL_DS when trying to start init process

On Thu,  9 Jun 2011 20:05:18 +0200
Mathias Krause <minipli@...glemail.com> wrote:

> Subject: [PATCH] exec: delay address limit change until point of no return
> 
> Unconditionally changing the address limit to USER_DS and not restoring
> it to its old value in the error path is wrong because it prevents us
> using kernel memory on repeated calls to this function. This, in fact,
> breaks the fallback of hard coded paths to the init program from being
> ever successful if the first candidate fails to load.
> 
> With this patch applied switching to USER_DS is delayed until the point
> of no return is reached which makes it possible to have a multi-arch
> rootfs with one arch specific init binary for each of the (hard coded)
> probed paths.
> 
> Since the address limit is already set to USER_DS when start_thread()
> will be invoked, this redundancy can be safely removed.

A couple of things here, please.

The description doesn't describe the user-visible symptoms of the bug. 
This makes it hard for the -stable maintainers to work out whether they
should accept the patch and it makes it hard for random distro
maintainers to determine whether your patch might fix a user bug report
which they're working on.

Secondly, I understand that we have identified changes which other arch
maintainers should make and test.  Please describe those changes to
make it easy for them and please also describe a way in which they can
test that change.

Both these things could be addressed using a description of some
testcase.

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