netdev - Re: [PATCH] net: openvswitch: datapath: fix data type in queue_gso

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2017 08:40:37 -0600
From:   "Gustavo A. R. Silva" <garsilva@...eddedor.com>
To:     David Miller <davem@...emloft.net>
Cc:     willemdebruijn.kernel@...il.com, pshelar@...ira.com,
        willemb@...gle.com, netdev@...r.kernel.org, dev@...nvswitch.org,
        linux-kernel@...r.kernel.org, steffen.klassert@...unet.com
Subject: Re: [PATCH] net: openvswitch: datapath: fix data type in
 queue_gso_packets


Quoting David Miller <davem@...emloft.net>:

> From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
> Date: Sat, 25 Nov 2017 16:15:01 -0500
>
>> On Sat, Nov 25, 2017 at 2:14 PM, Gustavo A. R. Silva
>> <garsilva@...eddedor.com> wrote:
>>> gso_type is being used in binary AND operations together with SKB_GSO_UDP.
>>> The issue is that variable gso_type is of type unsigned short and
>>> SKB_GSO_UDP expands to more than 16 bits:
>>>
>>> SKB_GSO_UDP = 1 << 16
>>>
>>> this makes any binary AND operation between gso_type and SKB_GSO_UDP to
>>> be always zero, hence making some code unreachable and likely causing
>>> undesired behavior.
>>>
>>> Fix this by changing the data type of variable gso_type to unsigned int.
>>>
>>> Addresses-Coverity-ID: 1462223
>>> Fixes: 0c19f846d582 ("net: accept UFO datagrams from tuntap and packet")
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@...eddedor.com>
>>
>> Acked-by: Willem de Bruijn <willemb@...gle.com>
>
> Applied and I'll queued this up with Willem's changes for -stable.
>
> Thanks!

Glad to help :)

Thanks
--
Gustavo A. R. Silva