Date: Wed, 6 Oct 2010 22:37:51 -0400 From: Dan Rosenberg <dan.j.rosenberg@...il.com> To: "Steven M. Christey" <coley@...us.mitre.org> Cc: oss-security@...ts.openwall.com, Eugene Teo <eugeneteo@...nel.sg> Subject: Re: CVE request: multiple kernel stack memory disclosures While these are pending, a few more of the same problem (uninitialized structure members being copied back to userspace, leaking kernel stack memory) have come up. These are similar or related to the previous ipc/sem.c leak. ipc/shm.c (shmctl), reported and fixed by Kees Cook Affects >= 2.6.0, >= 2.4.0 Reference: http://lkml.org/lkml/2010/10/6/454 ipc/compat.c (compat versions of semctl, shmctl, and msgctl) Affects >= 2.6.8 ipc/compat_mq (compat versions of mq_open and mq_getsetattr) Affects >= 2.6.8 Reference: http://lkml.org/lkml/2010/10/6/492 -Dan On Wed, Oct 6, 2010 at 4:02 PM, Dan Rosenberg <dan.j.rosenberg@...il.com> wrote: > I'll omit descriptions here to save space, since they were already > provided. I'll keep the same organization as last time, just to make > it easier. Issues that haven't been fixed yet are for the most part > planned for 2.6.37. Patches were submitted for all issues, so it's > mostly just a matter of time. > > --- > > TIOCGICOUNT stack leaks: > > usb/serial/mos*.c > Fixed in 2.6.36-rc5 > Affects >= 2.6.19 > > drivers/serial/serial_core.c > Not fixed yet (Alan Cox's fix will be in 2.6.37) > Affects >= 2.6.0 > > drivers/char/amiserial.c > Not fixed yet (Alan Cox's fix will be in 2.6.37) > Affects >= 2.6.0, >= 2.4.0 > > drivers/char/nozomi.c > Not fixed yet (Alan Cox's fix will be in 2.6.37) > Affects >= 2.6.25 > > drivers/net/usb/hso.c (CVE-2010-3298) > Fixed in 2.6.36-rc5 > Affects >= 2.6.29 > > --- > > FBIOGET_VBLANK stack leaks: > > drivers/video/sis/sis_main.c > Fixed in 2.6.36-rc6 > Affects >= 2.6.11 > > drivers/video/ivtv/ivtvfb.c > Not fixed yet (patch has been queued) > Affects >= 2.6.24 > > --- > > Miscellaneous device ioctl stack leaks: > > sound/pci/rme9652/hdsp*.c > Fixed in 2.6.36-rc6 > Affects >= 2.6.0 (hdsp.c), >= 2.6.13 (hdspm.c) > > drivers/video/via/ioctl.c > Fixed in 2.6.36-rc5 > Affects >= 2.6.28 > > drivers/net/cxgb3/cxgb3_main.c (CVE-2010-3296) > Fixed in 2.6.36-rc5 > Affects >= 2.6.21 > > drivers/net/eql.c (CVE-2010-3297) > Fixed in 2.6.36-rc5 > Affects >= 2.6.0, >= 2.4.0 > > --- > > System call stack leak: > > ipc/sem.c > Not fixed yet (patch queued) > Affects >= 2.6.0, >= 2.4.0 > > > > Whew. > > -Dan > > On Wed, Oct 6, 2010 at 2:10 PM, Steven M. Christey > <coley@...us.mitre.org> wrote: >> >> When dealing with findings of this scale, sometimes the best we can do >> (within a reasonable amount of time) is to combine things. >> >> Let's consider the general guidelines of "split by vuln type" and "split by >> affected version." Although the severity of each bug may vary, they all >> appear to be related to "not initializing re-used memory." >> >> The remaining question is how to determine "affected version." Ideally one >> might like to know the minimum set of affected versions for each bug (both >> in 2.6 and 2.4), but this might not be readily available. We could then >> just decide to split things based on which bugs got fixed in which 2.6.x.y >> release. If Dan, Eugene, or someone else has that kind of information >> (which is painful for me to research as a kernel "outsider"), then we can >> group bugs that are fixed in the same 2.6.x.y release, then assign a single >> CVE to each group. >> >> We effectively exclude those one-off issues that are already assigned CVEs. >> >> - Steve >> >
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