Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

From: Borislav Petkov
Date: Thu Nov 29 2012 - 14:24:59 EST


On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > Can you do:
> >
> > make arch/x86/kernel/ptrace.lst
> >
> > and send me that file, privately is fine too.
>
> Done, =)

Ok, thanks. Here it is:

ffffffff8100b627: 83 3f 00 cmpl $0x0,(%rdi)
ffffffff8100b62a: 75 24 jne ffffffff8100b650 <syscall_trace_enter+0x163>
ffffffff8100b62c: eb 37 jmp ffffffff8100b665 <syscall_trace_enter+0x178>
ffffffff8100b62e: 65 48 8b 0c 25 00 00 mov %gs:0x0,%rcx
ffffffff8100b635: 00 00
ffffffff8100b633: R_X86_64_32S current_task
extern void __audit_seccomp(unsigned long syscall, long signr, int code);
extern void __audit_ptrace(struct task_struct *t);

static inline int audit_dummy_context(void)
{
void *p = current->audit_context;
ffffffff8100b637: 48 8b 89 c0 04 00 00 mov 0x4c0(%rcx),%rcx
regs->orig_ax,
regs->bx, regs->cx,
regs->dx, regs->si);
#ifdef CONFIG_X86_64
else
audit_syscall_entry(AUDIT_ARCH_X86_64,
ffffffff8100b63e: 4c 8b 4b 38 mov 0x38(%rbx),%r9
ffffffff8100b642: 48 8b 53 70 mov 0x70(%rbx),%rdx
return !p || *(int *)p;
ffffffff8100b646: 48 85 c9 test %rcx,%rcx
ffffffff8100b649: 74 05 je ffffffff8100b650 <syscall_trace_enter+0x163>
ffffffff8100b64b: 83 39 00 cmpl $0x0,(%rcx)
ffffffff8100b64e: 74 1f je ffffffff8100b66f <syscall_trace_enter+0x182>
regs->di, regs->si,
regs->dx, regs->r10);
#endif

out:
return ret ?: regs->orig_ax;
ffffffff8100b650: 48 83 ca ff or $0xffffffffffffffff,%rdx
ffffffff8100b654: 48 85 ed test %rbp,%rbp
ffffffff8100b657: 75 04 jne ffffffff8100b65d <syscall_trace_enter+0x170>
ffffffff8100b659: 48 8b 53 78 mov 0x78(%rbx),%rdx
}
ffffffff8100b65d: 5b pop %rbx
ffffffff8100b65e: 5d pop %rbp
ffffffff8100b65f: 48 89 d0 mov %rdx,%rax
ffffffff8100b662: 41 5c pop %r12
ffffffff8100b664: c3 retq

We're calling audit_syscall_entry() for a 64-bit task (chrome) and we
check whether the audit context of the task is not a dummy one.

We fail at the second check in

return !p || *(int *)p;

when we're trying to deref the ->audit_context pointer of current and
then check it for being 0 in audit_syscall_entry. It turns out it is
some random crap, as we saw already: RCX=0000000000000063.

>From looking at the code, task audit contexts get normally allocated
at fork time and dealloc'd at task exit time so your process should
actually have a valid task context.

The only explanation I have is that it could be some random corruption
which f*cked up the ->audit_context pointer but I might be wrong. Btw,
do you have CONFIG_AUDITSYSCALL enabled in your kernel?

I'd say right now we could watch this and if it is reproducible, then
we can involve some more brain power and skills into it. If it has been
only a single occurrence, then we'll write it on the random corruption's
tab.

Thanks.

--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/