Secure testing team - Mar 2006 - CVE-2005-2973: Yet another kernel DoS

On Mon, 2005-10-24 at 19:39 +0200, Florian Weimer wrote:
> * dann frazier:
> 
> > Horms: I realize you might be somewhat out of the loop as to how
we''re
> > abusing your directory tree; I''ll catch you on IRC when
you''re back to
> > explain in detail.
> 
> Could you write a short statement to the mailing lists, please?
Sure - good idea.

Micah and I have created an evolving schema, using rfc822-style files.
Currently we''re storing this data in
svn://svn.debian.org/svn/kernel/people/horms/patch_notes, though we
should probably move it elsewhere once we''ve settled on the
architecture.

I proposed the rfc822 layout because its familiar to Debian people, and
I have a small python library that I can use to read & write this
format.

The idea is we''d have one rfc822 file per patch, and include all
relevant information there - including CVE status, inclusion status
across currently maintained source trees, description information, etc.
If you look in Horms'' cve directory today you''ll see a lot of
CAN-XXXX-XXXX files - we''re thinking about making this ID just a field
in the file named after the patch, so those may go away - ignore them
for now.

Currently, our file layout looks like this (slightly modified for
example''s sake):

$ cat net-ipv6-udp_v6_get_port-loop.patch
=====================================================Candidate: CVE-2005-2973
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2973
Reference:
CONFIRM:http://linux.bkbits.net:8080/linux-2.6/cset@4342df67SNhRx_3FGhUrrU-FXLlQIA
Description:
 Fix infinite loop in udp_v6_get_port().
Bug:
fixed-upstream: 2.6.14-rc4, 2.6.13.3
2.6.13: released (2.6.13+2.6.14-rc4-0experimental.1)
2.6.8-sarge-security: pending (2.6.8-16sarge2)
2.4.27-sarge-security: pending (2.4.27-10sarge2)
>From here you can gather that this is a security fix that went into
2.6.14-rc4.  Its been released in our 2.6.13 source tree, starting in
version 2.6.13+2.6.14-rc4-0experimental.1.
> For example, I''d like to get a list of the 2.6.12.6 security bugs
> which have *not* been assigned CVE names.  Which data sources shall I
> combine to obtain this information?
Eventually, and this is very subject to change - especially as we
haven''t discussed this with Horms yet, you should be able to follow
this
process:

Look in all files for a fixed-upstream field containing 2.6.12.6.  In
those that match, look for a Candidate field with the string
"##NEEDED##".

I think the biggest problem your example will have with this data format
is that we aren''t tracking patches by the upstream release they arrived
in.  You''ll have to count on either having your own list of patches
that
came with 2.6.12.6 and mapping those to our patch names, or count on
someone being diligent enough to keep the fixed-upstream field up to
date.
-- 
dann frazier <dannf@dannf.org>

On Tue, Oct 25, 2005 at 08:56:27PM -0600, dann frazier
wrote:
> On Mon, 2005-10-24 at 19:39 +0200, Florian Weimer wrote:
> > * dann frazier:
> > 
> > > Horms: I realize you might be somewhat out of the loop as to how
we''re
> > > abusing your directory tree; I''ll catch you on IRC when
you''re back to
> > > explain in detail.
> > 
> > Could you write a short statement to the mailing lists, please?
> 
> Sure - good idea.
I just took a quick peak at whats been going on, 
and it looks completely awsome. I''ll send some more
feedback once I have something new to add and play around
a bit. Which shouldn''t be very long.

-- 
Horms

* dann frazier:
> Horms: I realize you might be somewhat out of the loop as to how
we''re
> abusing your directory tree; I''ll catch you on IRC when
you''re back to
> explain in detail.
Could you write a short statement to the mailing lists, please?

For example, I''d like to get a list of the 2.6.12.6 security bugs
which have *not* been assigned CVE names.  Which data sources shall I
combine to obtain this information?

(Trimming the Cc: list.)

On Mon, Oct 24, 2005 at 11:29:48AM -0600, dann frazier
wrote:
> On Mon, 2005-10-24 at 10:28 +0200, Moritz Muehlenhoff wrote:
> > Hi,
> > an infinite loop in udp_v6_get_port() can be triggered and thus result
in
> > local DoS. Please see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170772
> > for a link to a patch by davem. This is CVE-2005-2973.
> 
> I''ve added this to svn as
> people/horms/patch_notes/cve/net-ipv6-udp_v6_get_port-loop.patch, and
> symlinked as CAN-2005-2973 for tracking.
> 
> Horms: I realize you might be somewhat out of the loop as to how
we''re
> abusing your directory tree; I''ll catch you on IRC when
you''re back to
> explain in detail.
I''ve made a few updates, putting this tree in the non-security 2.4.27 
and 2.6.8 branches, and submitting it for inclusion in 2.4.32-rc2


-- 
Horms

On Mon, 2005-10-24 at 10:28 +0200, Moritz Muehlenhoff
wrote:
> Hi,
> an infinite loop in udp_v6_get_port() can be triggered and thus result in
> local DoS. Please see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170772
> for a link to a patch by davem. This is CVE-2005-2973.
I''ve added this to svn as
people/horms/patch_notes/cve/net-ipv6-udp_v6_get_port-loop.patch, and
symlinked as CAN-2005-2973 for tracking.

Horms: I realize you might be somewhat out of the loop as to how we''re
abusing your directory tree; I''ll catch you on IRC when you''re
back to
explain in detail.
> There''s also another link to a possible regression for a dst mem
leak fix. Does this
> apply to the Debian kernel as well?
I''ll check.

Hi,
an infinite loop in udp_v6_get_port() can be triggered and thus result in
local DoS. Please see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170772
for a link to a patch by davem. This is CVE-2005-2973.
There''s also another link to a possible regression for a dst mem leak
fix. Does this
apply to the Debian kernel as well?

Cheers,
        Moritz