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 ?
> 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
