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] [day] [month] [year] [list]

Message-ID: <20121130010035.GA5042@liondog.tnic>
Date:	Fri, 30 Nov 2012 02:00:35 +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 Fri, Nov 30, 2012 at 12:56:08AM +0100, Ian Kumlien wrote:
> > 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.
> 
> Weird, and this should be allocated automatically?

Yes, during task creation in copy_process we do audit_alloc and in
do_exit() we do audit_free.

> > 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?
> 
> grep CONFIG_AUDITSYSCALL .config
> CONFIG_AUDITSYSCALL=y

Ok.

> > 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.
> 
> Uhmmm oki

Right, so thinking purely hypothetically I can imagine that there might
be some small window where we're in the process of freeing the audit
context during task exit and we issue a syscall which gets traced and we
end up in the audit_syscall_entry but AFAICT when we free the context,
we do get it and do tsk->audit_context = NULL which cannot explain the
funny ECX value. Hmm, strange.

But it doesn't bring a whole lot in us conjecturing what has happened if
this cannot be reliably reproduced so please watch your box and be on
alert for similar oopses and the steps you've made to cause them.

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/