Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 16 Oct 2015 19:46:17 +0200
From: Salva Peiró <speiro@....upv.es>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request: Linux Kernel heap corruption on debug_read_tlb

On 10/16/15, Florian Weimer <fweimer@...hat.com> wrote:
> On 10/15/2015 03:53 PM, Greg KH wrote:
>> On Thu, Oct 15, 2015 at 10:30:04AM +0200, Salva Peiró wrote:
>>> Hello,
>>>
>>> Is there a CVE for this? If not, could one be assigned, please?
>>>
>>>      https://patchwork.kernel.org/patch/6853351/
>>>      commit e203db293863fa15b4b1917d4398fb5bd63c4e88
>>>      iommu/omap: Fix debug_read_tlb() to use seq_printf()
>>>
>>>      The debug_read_tlb() uses the sprintf() functions directly on the
>>> buffer
>>>      allocated by buf = kmalloc(count), without taking into account the
>>> size
>>>      of the buffer, with the consequence corrupting the heap, depending
>>> on
>>>      the count requested by the user.
>>>
>>>      The patch fixes the issue replacing sprintf() by seq_printf().
>>
>> For a root-only-readable file?  Why is a CVE needed?
>
> Fedora and downstreams do not system-level access to the root user by
> default, as a result of the custom Secure Boot patches.  This does not
> matter for pure denial-of-service bugs of course, but this bug looks
> like something that might allow code execution.
>
> Florian
>

The value that corrupts the SLUB allocator freelist pointer is known and
predictable. In principle, it should be possible to mmap() that pointer
to a user controlled page, so the SLUB allocator ends up managing a
user-controlled memory memory block.
--
salva

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