On Wed, Jun 8, 2011 at 4:00 AM, Linus Torvalds <[email protected]> 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 <[email protected]> --- 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 _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
