Re: CVE request: kernel: CAN information leak, 2nd attempt

[Dan Rosenberg <dan.j.rosenberg () gmail com>]

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.

-Dan

On Mon, Dec 20, 2010 at 1:36 PM, Petr Matousek <pmatouse () redhat com> 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:
> https://bugzilla.redhat.com/show_bug.cgi?id=664544
> http://seclists.org/oss-sec/2010/q4/103
>
> 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] http://seclists.org/oss-sec/2010/q4/107
>  [2] http://lists.opensuse.org/opensuse-updates/2010-12/msg00026.html
>  [3] http://www.debian.org/security/2010/dsa-2126
>  [4] http://www.cs.brown.edu/people/drosenbe/research.html
>
> 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