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

From: Daniel Axtens <dja-Yfaxwxk/[email-masked]>
Date: Fri, 19 Jan 2018 01:05:15 +1100

Daniel Axtens <[email-masked]> writes:

> Jason Wang <[email-masked]> writes:
>
>> On 2018年01月18日 16:28, Pravin Shelar wrote:
>>> On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens <[email-masked]> 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.
>
> I don't think gso_max_size is quite the same. If I understand
> net/ipv4/tcp.c correctly, gso_max_size is supposed to cap the total
> length of the skb, not the length of each segmented packet. The problem
> for the bnx2x card is the length of the segment, not the overall length.
>
>>
>> Btw, looks like this could be triggered from a guest which is a DOS. We 
>> need request a CVE for this.
>>
>
> You are correct about how this can be triggered: in fact it came to my
> attention because a network packet from one LPAR (PowerVM virtual
> machine) brought down the card attached to a different LPAR. It didn't
> occur to me that it was potentially a security issue. I am talking with
> the security team at Canonical regarding this.

I have requested a CVE from the Distributed Weakness Filing.

Regards,
Daniel

>
> Regards,
> Daniel
>
>> 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: [email-masked]
>>>> Cc: [email-masked]
>>>>
>>>> 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
>>>>
_______________________________________________
dev mailing list
[email-masked]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev