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