Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 14 Nov 2010 11:09:34 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: econet iovec

This also raises a question of whether it's worth assigning CVEs to
every vulnerability that was fixed by a single change in the core
code.  I'm leaning towards "no".

-Dan

On Sun, Nov 14, 2010 at 11:06 AM, Dan Rosenberg
<dan.j.rosenberg@...il.com> wrote:
> Yes, this size calculation can overflow, but there's no negative
> effect, since it is only used to construct a UDP packet, and UDP is
> not susceptible to overflow issues in its sendmsg() path.
>
> On the other hand, the check on line 331 to put an upper bound on the
> total size can overflow, causing an underallocation on line 344 and a
> kernel panic on subsequent usage due to bad skbuff alignment.  This
> only affects people using actual native Econet hardware.  This was
> already fixed by recently added checks in iovec size calculations and
> in the sendto() path for maximum packet size.
>
> -Dan
>
> On Sun, Nov 14, 2010 at 9:56 AM, Thomas Pollet <thomas.pollet@...il.com> wrote:
>> Hi,
>>
>> the AF_ECONET sendmsg iovec code also appears to be vulnerable to an integer
>> overflow that will be fixed by the verify_iovec changes in the 2.6.37
>> kernel.
>> on line 469: size += iov_len
>>
>> Regards,
>> Thomas
>>
>

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.