Re: 3.15: kernel BUG at kernel/auditsc.c:1525!
From: Josh Boyer
Date: Mon Jun 23 2014 - 17:04:37 EST
On Fri, Jun 20, 2014 at 11:41 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Mon, Jun 16, 2014 at 2:48 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>> On 06/16/2014 02:35 PM, Andy Lutomirski wrote:
>>>
>>> To hpa, etc: It appears that entry_32.S is missing any call to the
>>> audit exit hook on the badsys path. If I'm diagnosing this bug report
>>> correctly, this causes OOPSes.
>>>
>>> The the world at large: it's increasingly apparent that no one (except
>>> maybe the blackhats) has ever scrutinized the syscall auditing code.
>>> This is two old severe bugs in the code that have probably been there
>>> for a long time.
>>>
>>
>> Yes, the audit code is a total mess.
>>
>>> The bad syscall nr paths are their own incomprehensible route
>>> through the entry control flow. Rearrange them to work just like
>>> syscalls that return -ENOSYS.
>>
>> I have to admit... it sort of lends itself to a solution like this:
>>
>> /* For the 64-bit case, analogous code for 32 bits */
>> movl $__NR_syscall_max+1,%ecx # *Not* __NR_syscall_max
>> cmpq %rcx,%rax
>> cmovae %rcx,%rax
>> movq %r10,%rcx
>> call *sys_call_table(,%rax,8)
>>
>> ... and having an extra (invalid) system call slot in the syscall table
>> beyond the end instead of branching off separately.
>>
>> (Note: we could use either cmova or cmovae, and either the 32- or 64-bit
>> form... the reason why is left as an exercise to the reader.)
>
> This is CVE-2014-4508, and it's probably worth fixing.
>
> Is my patch good? I can resent and cc stable if needed.
I'm planning on picking this up for Fedora tomorrow unless someone
screams it's the wrong fix. Honestly though, it would be nice to get
an indication either way.
josh
--
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/