Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Nov 2010 07:24:02 -0500 (EST)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Petr Matousek <pmatouse@...hat.com>, coley@...us.mitre.org
Subject: Re: CVE request: kernel: L2TP send buffer allocation
 size overflows

I don't understand this comment. Is he saying every send/recv in the kernel
suffers from this? The below CVE id really only applies to the l2tp
overflows.

Thanks.

-- 
    JB

----- "Thomas Biege" <thomas@...e.de> wrote:

> A comment from our kernel maintainer Jeff:
> "That applies to overflows for any send/recv not just the l2tp ones. I
> can use
> that CVE if there isn't another one, though."
> 
> Is this known? Should we use only on CVE-ID here?
> 
> 
> Bye
> Thomas
> 
> 
> Am Mittwoch 10 November 2010 20:44:11 schrieb Josh Bressers:
> > Please use CVE-2010-4160.
> > 
> > Thanks.
> > 
> > > "Both PPPoL2TP (in net/l2tp/l2tp_ppp.c, pppol2tp_sendmsg()) and
> > > IPoL2TP (in
> > > net/l2tp/l2tp_ip.c, l2tp_ip_sendmsg()) make calls to
> sock_wmalloc()
> > > that
> > > perform arithmetic on the size argument without any maximum bound.
> As
> > > a result,
> > > by issuing sendto() calls with very large sizes, this allocation
> size
> > > will wrap
> > > and result in a small buffer being allocated, leading to ugliness
> > > immediately
> > > after (probably kernel panics due to bad sk_buff tail position,
> but
> > > possibly
> > > kernel heap corruption)."
> > >
> > > Credit: Dan Rosenberg
> > >
> > > Reference:
> > > http://www.spinics.net/lists/netdev/msg145673.html
> > > https://bugzilla.redhat.com/show_bug.cgi?id=651892
> > >
> > > Thanks,
> > > --
> > > Petr Matousek / Red Hat Security Response Team
> > 
> 
> -- 
>  Thomas Biege <thomas@...e.de>, SUSE LINUX, Security Support &
> Auditing
>  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
> --
>   Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
>                             -- Marie von Ebner-Eschenbach

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