linux-kernel - Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121129192500.GG30789@liondog.tnic>
Date:	Thu, 29 Nov 2012 20:25:00 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Ian Kumlien <pomac@...or.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] NULL pointer dereference in 3.7-rc7 (syscall_trace_enter)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/