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

From: Daniel Axtens <dja-Yfaxwxk/+vWsTnJN9+BGXg@public•gmane.org>
To: Jason Wang <jasowang-H+wXaHxf7aLQT0dZR+AlfA@public•gmane.org>,
	Pravin Shelar <pshelar-LZ6Gd1LRuIk@public•gmane.org>
Cc: ovs dev <dev-yBygre7rU0TnMu66kgdUjQ@public•gmane.org>,
	Linux Kernel Network Developers
	<netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org>,
	Manish.Chopra-YGCgFSpz5w/QT0dZR+AlfA@public•gmane.org
Subject: Re: [PATCH 0/3] Check gso_size of packets when forwarding
Date: Fri, 19 Jan 2018 01:05:15 +1100	[thread overview]
Message-ID: <87d1275kkk.fsf@linkitivity.dja.id.au> (raw)
In-Reply-To: <87fu735ms5.fsf-hbezLPf06/Fz8PszVLmxdVaj5H9X9Tb+@public.gmane.org>

Daniel Axtens <dja@axtens•net> writes:

> Jason Wang <jasowang@redhat•com> writes:
>
>> On 2018年01月18日 16:28, Pravin Shelar wrote:
>>> On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens <dja@axtens•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.
>
> 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: Manish.Chopra@cavium•com
>>>> Cc: dev@openvswitch•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
>>>>
_______________________________________________
dev mailing list
dev@openvswitch•org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev