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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue,  9 Dec 2008 20:04:17 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Ulrich Weigand <ulrich.weigand@...ibm.com>
Subject: Re: [PATCH, RFC] revert breakage from "tracehook: exec"

Thanks for the report, good catch.  I've written a test case for the bug
(I'll include it with the patch I post momentarily).  (Note to testers:
this bug does not manifest on Fedora kernels.)

I still think it's preferable to have the only tracehook calls be in core
code, rather than in binfmt modules.  It seems much less error-prone in the
long run.  Also, since we no longer export ptrace_notify(), we'd have to
revert that as well to move the calls into binfmt modules when built as
modules (I think your patch will barf on CONFIG_BINFMT_AOUT=m, e.g.).

One option would be to move the call further out, to do_execve (and
compat_do_execve).  But I would like to keep the binfmt and bprm pointers
available in tracehook_report_exec() with full information about the binfmt
and bprm->file still available.  Even though that's not currently used, it
will clearly be desireable for future tracing facilities to be able to
scavenge details from there.

My fix (next posting) leaves the call in search_binary_handler(),
but makes it only on the outermost call (using bprm->recursion_depth).


Thanks,
Roland
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ