Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 May 2014 18:31:56 -0700
From: Andy Lutomirski <>
To: Steve Grubb <>
Subject: Re: CVE request: Linux kernel DoS with syscall auditing

On Wed, May 28, 2014 at 6:06 PM, Steve Grubb <> wrote:
> On Wednesday, May 28, 2014 02:45:59 PM Andy Lutomirski wrote:
>> Issuing a system call with a random large number will OOPS, depending
>> on configuration.  A configuration that will enable this bug is:
>> # auditctl -a exit,always -S open
>> No privilege whatsoever is required to trigger the OOPS.
> Do you have more information about this? I don't get an oops and I run with
> the audit system on all the time.

It's on lkml -- see:

You need to pass a fairly large bogus syscall number.  The auditsc
code is completely missing any bounds checking on the syscall numbers.

>> It's possible that this can be extended to more than just a DoS --
>> with some care and willingness to exploit timing attacks, this is a
>> read of arbitrary single bits in kernel memory.
> What platform? Where do the arbitrary bits go? What syscall are we talking
> about?

The audit system decides whether to log a syscall depending on a bit
in the audit_krule mask.  Since the mask read isn't bounds-checked,
the caller can force it to read any bit, relative to the audit_krule.
Anything that can tell the attacker the outcome of the filter decision
will reveal the value of that bit.

> There is a linux-audit mail list which seems to not have any emails about this
> problem. That is really the best place to discuss any issues with this
> subsystem and get it fixed.

There's already a patch on lkml.

I'll cc linux-audit for the v2 patches.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ