REDHAT-BUG-449359: Null Pointer Dereference
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.
Affected Software
Event History
Frequently Asked Questions
What is the severity of REDHAT-BUG-449359?
The severity of REDHAT-BUG-449359 is currently classified based on its potential impact on the security of the affected systems.
How do I fix REDHAT-BUG-449359?
To fix REDHAT-BUG-449359, users should apply the appropriate kernel updates provided by Red Hat or Fedora.
Which systems are affected by REDHAT-BUG-449359?
REDHAT-BUG-449359 affects Red Hat Enterprise Linux versions from 5 and Fedora Core versions from 6.
Is REDHAT-BUG-449359 a remote vulnerability?
No, REDHAT-BUG-449359 is not characterized as a remote vulnerability but rather involves local process manipulation.
When was REDHAT-BUG-449359 reported?
REDHAT-BUG-449359 was reported by Alexei Dobryanov and involves a kernel utrace related issue.