Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 16 Oct 2015 19:46:17 +0200
From: Salva Peiró <>
Subject: Re: CVE Request: Linux Kernel heap corruption on debug_read_tlb

On 10/16/15, Florian Weimer <> 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?
>>>      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.

Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.