netdev - Re: [PATCH 0/3] Check gso_size of packets when forwarding

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 Jan 2018 17:49:14 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Pravin Shelar <pshelar@....org>, Daniel Axtens <dja@...ens.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Manish.Chopra@...ium.com, ovs dev <dev@...nvswitch.org>
Subject: Re: [PATCH 0/3] Check gso_size of packets when forwarding



On 2018年01月18日 16:28, Pravin Shelar wrote:
> On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens <dja@...ens.net> wrote:
>> When regular packets are forwarded, we validate their size against the
>> MTU of the destination device. However, when GSO packets are
>> forwarded, we do not validate their size against the MTU. We
>> implicitly assume that when they are segmented, the resultant packets
>> will be correctly sized.
>>
>> This is not always the case.
>>
>> We observed a case where a packet received on an ibmveth device had a
>> GSO size of around 10kB. This was forwarded by Open vSwitch to a bnx2x
>> device, where it caused a firmware assert. This is described in detail
>> at [0] and was the genesis of this series. Rather than fixing it in
>> the driver, this series fixes the forwarding path.
>>
> Are there any other possible forwarding path in networking stack? TC
> is one subsystem that could forward such a packet to the bnx2x device,
> how is that handled ?

Yes, so it looks to me we should do the check in e.g netif_needs_gso() 
before passing it to hardware. And bnx2x needs to set its gso_max_size 
correctly.

Btw, looks like this could be triggered from a guest which is a DOS. We 
need request a CVE for this.

Thanks

>
>> To fix this:
>>
>>   - Move a helper in patch 1.
>>
>>   - Validate GSO segment lengths in is_skb_forwardable() in the GSO
>>     case, rather than assuming all will be well. This fixes bridges.
>>     This is patch 2.
>>
>>   - Open vSwitch uses its own slightly specialised algorithm for
>>     checking lengths. Wire up checking for that in patch 3.
>>
>> [0]: https://patchwork.ozlabs.org/patch/859410/
>>
>> Cc: Manish.Chopra@...ium.com
>> Cc: dev@...nvswitch.org
>>
>> Daniel Axtens (3):
>>    net: move skb_gso_mac_seglen to skbuff.h
>>    net: is_skb_forwardable: validate length of GSO packet segments
>>    openvswitch: drop GSO packets that are too large
>>
>>   include/linux/skbuff.h  | 16 ++++++++++++++++
>>   net/core/dev.c          |  7 ++++---
>>   net/core/skbuff.c       | 34 ++++++++++++++++++++++++++++++++++
>>   net/openvswitch/vport.c | 37 ++++++++++++++++++++++++++++++-------
>>   net/sched/sch_tbf.c     | 10 ----------
>>   5 files changed, 84 insertions(+), 20 deletions(-)
>>
>> --
>> 2.14.1
>>