From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: [Patch net v2] mlx5: fixup checksum for short ethernet frame padding
Date: Wed, 28 Nov 2018 15:57:09 -0800
Message-ID: <CAM_iQpWXXM3F28b8XLURCJJQaTVK++P9U+u=dehCbqqKEE8VHA@mail.gmail.com>
References: <20181128061013.3885-1-xiyou.wangcong@gmail.com>
 <CANn89iL4KM+VpE2ziHvppXZWhGUz-uuaMYTQPMkfxQooc4OpDw@mail.gmail.com>
 <CAM_iQpX2uidJu5ijU7NAVTHm=kNQ+ppvnABZzpbqV53ZqC0mfQ@mail.gmail.com> <CANn89iKDNfUP4VzNMxNwKwO8+gyxZwKBr9nSFAeecripnGPYNw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
        Saeed Mahameed <saeedm@mellanox.com>
To: Eric Dumazet <edumazet@google.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg1-f195.google.com ([209.85.215.195]:41259 "EHLO
        mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726328AbeK2LAn (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 29 Nov 2018 06:00:43 -0500
Received: by mail-pg1-f195.google.com with SMTP id 70so38087pgh.8
        for <netdev@vger.kernel.org>; Wed, 28 Nov 2018 15:57:21 -0800 (PST)
In-Reply-To: <CANn89iKDNfUP4VzNMxNwKwO8+gyxZwKBr9nSFAeecripnGPYNw@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, Nov 28, 2018 at 3:50 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Wed, Nov 28, 2018 at 2:16 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 7:00 AM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > Nice packet of death alert.
> > >
> > > pad_len can be 0xFFFFFF67  here, if frame_len is smaller than pad_offset.
> >
> > Unless IP header is malformed, how could it be?
>
> This is totally something an attacker can forge.

Of course, as in the email I sent to mellanox guys,__vlan_get_protocol()
could _literately_ exhaust all skb->len. If no sufficient skb tail room,
we could even possibly crash.

But again, I kinda feel the hardware already does the sanity check,
otherwise we have much more serious trouble in mlx5e_lro_update_hdr()
which parses into TCP header.

Thanks.