Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Dec 2010 15:43:44 -0500 (EST)
From: "Steven M. Christey" <>
To: Petr Matousek <>
cc: "Steven M. Christey" <>,,
        Dan Rosenberg <>
Subject: Re: CVE request: kernel: CAN information leak, 2nd

Hmmm, a couple things going on here.  I'm fine with associating 
CVE-2010-3874 with the overflow.  But note - if the overflow does not 
affect any decision-making, bypass protection logic, or cause a DoS (e.g. 
if certain values of the overflowed field cause a CPU hit), then it's 
probably OK to treat it as non-security.  There hasn't been much security 
analysis done in semantic overflows and we probably have to treat them on 
a case-by-case basis.  For example - if the last field happens to be a 
bank account balance, or a flag stating whether a user has some kind of 
special privilege, then that's a security issue even without memory 
corruption (or rather, it's still "memory" corruption, just not with the 
same kinds of management structures that we usually run into currently).

Use CVE-2010-4565 for the kernel address leak.

- Steve

On Mon, 20 Dec 2010, Petr Matousek wrote:

> ----- Original Message -----
>> I'm ok with this, but I wanted to point out that the previously
>> mentioned heap overflow is a semantic overflow only. Because the
>> field that is being overflowed is the last field in a struct that is
>> always allocated in a chunk significantly larger than the struct
>> itself, the overflow will never result in any kind of corruption, so
>> it has essentially no security impact.
> Yes, we are aware of this [1]. Personally I'd call it a mitigation factor
> even though I don't have a strong opinion here. Steve, could you please
> comment?
>  [1]
> Petr
>> -Dan
>> On Mon, Dec 20, 2010 at 1:36 PM, Petr Matousek <>
>> wrote:
>>> "The CAN protocol uses the address of a kernel heap object as a proc
>>> filename, revealing information that could be useful during
>>> exploitation."
>>> Reference:
>>> Credit: Dan Rosenberg
>>> ------------
>>> Please note that there has been one attempt to request CVE for this
>>> issue already [1]. The problem is that vendors (Red Hat more or less
>>> included) used the assigned CVE for the potential heap overflow
>>> issue
>>> [2, 3] whereas reporter used it for information leak [4].
>>>  [1]
>>>  [2]
>>>  [3]
>>>  [4]
>>> I'd suggest to keep the CVE-2010-3874 id for the heap overflow which
>>> has some (although very limited) security potential and assign a new
>>> id
>>> for the information leak.
>>> Thanks,
>>> --
>>> Petr Matousek / Red Hat Security Response Team

Powered by blists - more mailing lists

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

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