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

[Petr Matousek <pmatouse () redhat com>]

----- 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] https://bugzilla.redhat.com/show_bug.cgi?id=649695#c7

Petr

> -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