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]

Date:	Wed,  8 Jun 2011 10:23:03 +0200
From:	Mathias Krause <minipli@...glemail.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	Al Viro <viro@...iv.linux.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Mathias Krause <minipli@...glemail.com>
Subject: Re: [PATCH] init: use KERNEL_DS when trying to start init process

On Wed, Jun 8, 2011 at 4:00 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> That said, that commit (it's commit ID 4095b99c09e3d in tglx's tree)
> predates the "real" BK history too: it's part of the (limited) 2.4.x
> history that was imported from the release patches into BK at the
> beginning of the use of BK. So at that point we didn't do indivual
> commits, it's just the import of the v2.4.3.7 -> v2.4.3.8 patch.
>
> But yeah, it's old and crufty. And I agree that usually the correct
> fix is to remove the set_fs() calls entirely.

So here it is. Solves the problem for me.

Mathias

-- >8 --
Subject: [PATCH] exec: keep address limit on exec errors

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 it is possible to have a multi-arch rootfs
having one arch specific init binary for each of the (hard coded) probed
paths.

Signed-off-by: Mathias Krause <minipli@...glemail.com>
---
 fs/exec.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index ea5f748..31df75f 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1357,10 +1357,6 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
 	if (retval)
 		return retval;
 
-	/* kernel module loader fixup */
-	/* so we don't try to load run modprobe in kernel space. */
-	set_fs(USER_DS);
-
 	retval = audit_bprm(bprm);
 	if (retval)
 		return retval;
-- 
1.5.6.5

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