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 13:45:29 -0500
From: Dan Rosenberg <>
To: Petr Matousek <>,, 
	"Steven M. Christey" <>
Subject: Re: CVE request: kernel: CAN information leak, 2nd attempt

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.


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