Re: 3.15: kernel BUG at kernel/auditsc.c:1525!

[Andy Lutomirski]

On Mon, Jun 16, 2014 at 10:59 AM, Toralf FÃrster <toralf.foerster@xxxxxx> wrote:
> On 06/16/2014 07:50 PM, Andy Lutomirski wrote:
>> cc: eparis.  This might be a new audit bug.
>>
>> On Mon, Jun 16, 2014 at 10:36 AM, Toralf FÃrster <toralf.foerster@xxxxxx> wrote:
>>> On 06/16/2014 07:32 PM, Andy Lutomirski wrote:
>>>> On Mon, Jun 16, 2014 at 10:29 AM, Richard Weinberger <richard@xxxxxx> wrote:
>>>>> Am 16.06.2014 19:25, schrieb Andy Lutomirski:
>>>>>> On Mon, Jun 16, 2014 at 10:21 AM, Richard Weinberger
>>>>>> <richard.weinberger@xxxxxxxxx> wrote:
>>>>>>> On Mon, Jun 16, 2014 at 6:33 PM, Toralf FÃrster <toralf.foerster@xxxxxx> wrote:
>>>>>>>> $ cat syscall.c
>>>>>>>> #include <unistd.h>
>>>>>>>> #include <sys/syscall.h>
>>>>>>>> int main(){return syscall(1000)!=-1;}
>>>>>>
>>>>>> What architecture are you building for?  On i386 and x86_64, 1000
>>>>>> shouldn't be big enough to trigger this.
>>>>>
>>>>> Toralf, is this an UML kernel?
>>>>>
>>>>
>>>> I'm also interested in the userspace architecture.  If it's x32
>>>> userspace, then I'm not surprised that there's a problem.
>>>
>>> It is a x86 system (ThinkPad T420) - not x32.
>>
>> I don't think this is CVE-2014-3917.  It looks like you're hitting this BUG:
>>
>> BUG_ON(context->in_syscall || context->name_count);
>>
>> Can you send the output of:
>>
>> auditctl -l [run as root]
>>
>> and
>>
>> dmesg |grep audit
>>
>> Are you using ptrace or anything like that (e.g. strace) when you
>> trigger this?  Are you using a funny glibc version?  Do you have
>> selinux or something like that enabled?
>>
>> --Andy
>>
> n22 ~ # auditctl -l
> LIST_RULES: exit,never arch=1073741827 (0x40000003) syscall=read,write,open,close,brk,fcntl,dup2,mmap,munmap,stat,fstat,nanosleep,rt_sigaction
>
>
> no ptrace/strace/SELinux, this is a stable x86 Gentoo Linux, glibc is 2.17, unstable are just KDE + Co.
>
> (@Richard: no. it is not an UML guest, I just stumbled over this while I tried to upgrade an unstable ~x86 Gentoo UML image using chroot)
>
> The trigger is just given by that C one-liner and kernel 3.15 (erm, I did not checked, if 3.14.x hit its too)

At the very least, it looks like sysret_audit can result in invoking
the audit exit hook twice. That's not what's causing this, but it
still looks fishy.

Toralf, can you run your test program under strace, post the output,
and see whether it still crashes?  There's some chance that strace
will "fix" it, since strace causes a different set of hooks to run.

Any ideas, Eric?

--Andy
--
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/