[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim4XUYUvk1qKzHjMfU=n8qc1e8SOM_-9FJv5daN@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
