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

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]

Date:	Mon, 23 Jun 2014 17:04:30 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Richard Weinberger <richard@....at>, X86 ML <x86@...nel.org>,
	Toralf Förster <toralf.foerster@....de>,
	Eric Paris <eparis@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 3.15: kernel BUG at kernel/auditsc.c:1525!

On Fri, Jun 20, 2014 at 11:41 AM, Andy Lutomirski <luto@...capital.net> wrote:
> On Mon, Jun 16, 2014 at 2:48 PM, H. Peter Anvin <hpa@...or.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/