[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Nov 2010 07:43:12 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.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
There are not overflows in every send/recv call. The fix that
addresses these issues in l2tp also addresses any other possible
examples of this problem in other protocols, including CVE-2010-3859
(heap overflow in TIPC).
-Dan
On Wed, Nov 24, 2010 at 7:24 AM, Josh Bressers <bressers@...hat.com> wrote:
> 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
