Description of problem:
Alexei Dobryanov has reported the following kernel utrace related issue (BZ#245735):
1. late ptracemayattach() check
static int ptraceattach(struct taskstruct task) { ... engine = utraceattach(task, (UTRACEATTACHCREATE | UTRACEATTACHEXCLUSIVE | UTRACEATTACHMATCHOPS), &ptraceutraceops, 0); [error checking] if (ptracemayattach(task)) { [more attaching process]
Doing may attach check there is asking for trouble, because utraceattach() will happily create and modify "struct utrace " and create and attach engines to it on task you don't have permissions. Order should be reverted. That's easy.
2. race around &deadengineops setting...
I originally thought #1 would lead to memory leaks, however, written dumb PTRACEATTACH'er gave much more amazing results.
The following program quickly (1 sec) oopses kernel when run against process you normally can't attach to (like normal user to getty processes)
#include <stdlib.h> #include <sys/ptrace.h>
int main(int argc, char argv[]) { pidt pid = atoi(argv[1]);
while (1) ptrace(PTRACEATTACH, pid, NULL, NULL);
return 0; }
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] reportquiescent+0x36/0x154 [<ffffffff8005f316>] utracequiescent+0x2b/0x238 [<ffffffff800601e9>] utracegetsignal+0x45d/0x4c0 [<ffffffff80039c6f>] getsignaltodeliver+0x169/0x47a [<ffffffff80008f5a>] donotifyresume+0xd0/0x7e2 [<ffffffff80203673>] spinunlockirqrestore+0x3f/0x45 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff801400c0>] ttyread+0x81/0xc7 [<ffffffff80202ede>] tracehardirqsonthunk+0x35/0x37 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff80009b43>] sysretsignal+0x21/0x31 [<ffffffff80009deb>] ptregscallcommon+0x67/0xac
This is a race we chatted with Roland about: http://marc.info/?l=linux-kernel&m=117863520707703&w=2
engine's flags and ops settings in utracedetach() and acting on them in reportquiescent():
utracedetach() reportquiescent() --------------- ------------------ [utrace lock held] [utrace lock is not held]
engine->flags = UTRACEEVENT(QUIESCE) | UTRACEACTIONQUIESCE;
if (engine->flags & UTRACEEVENT(QUIESCE)) REPORT(reportquiesce);
rcuassignpointer(engine->ops, &deadengineops);
At the moment of REPORT call engine's ops are still "live" ptrace ops which do not have ->reportquiesce callback. So, there will oops while calling function at NULL address. "Dead" ptrace engine ops do have dummy callback but it wasn't yet glued.
Obviously, patch #1 won't fix this.
3. Looks like nobody filed double free at utrace aka oops at rcuprocesscallbacks() against RHEL5 kernel.
It's bug https://bugzilla.redhat.com/bugzilla/showbug.cgi?id=207002 against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.
Double free vulnerability in the utrace support in the Linux kernel, probably 2.6.18, in Red Hat Enterprise Linux (RHEL) 5 and Fedora Core 6 (FC6) allows local users to cause a denial of service (oops), as demonstrated by a crash when running the GNU GDB testsuite, a different vulnerability than CVE-2008-2365.