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: <CA+5PVA70nFS8JZkL0-Q-1HjFHT5NA04275_M4WstjQMrpT+hrQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ