[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Sep 2009 22:33:51 +0200
From: Willy Tarreau <w@....eu>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE request: kernel: tc: uninitialised kernel memory leak
Hi Alexander,
On Sat, Sep 05, 2009 at 09:52:50PM +0400, Solar Designer wrote:
> On Thu, Sep 03, 2009 at 11:45:03AM +0800, Eugene Teo wrote:
> > Three bytes of uninitialised kernel memory are currently leaked to user.
> >
> > http://patchwork.ozlabs.org/patch/32830/
> > https://bugzilla.redhat.com/show_bug.cgi?id=520990
>
> 2.4 kernels appear to be affected as well, and moreover they appear to
> require at least some of these older fixes as well:
>
> http://marc.info/?l=git-commits-head&m=112002138324380
Thanks for letting me know.
I'm late on fixes these days. I still have several ones to apply but
need to find time to work on them.
> Specifically, in net/sched/sch_api.c both tc_fill_qdisc() and
> tc_fill_tclass() are affected - the former was fixed in 2.6 in 2005,
> the latter is being fixed now.
>
> I'm not sure what this means for CVE. Should there be another CVE id
> for the issues fixed in 2.6 in 2005 (if one was not allocated at the
> time), and 2.4 could reference both CVE ids now?
Personally I have no problem referencing an old CVE in a recent
commit if it helps tracking common bugs. And I think we've already
done that in the past.
> I did not check if any of the affected code is possibly normally only
> available to root, but even if so the issue may be relevant on systems
> with containers.
In general I tend to consider those "bytes leak" bugs with lower
importance, but they need to be fixed anyway since they may eventually
impact some random setup somewhere.
Thanks,
Willy
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