netdev - Re: EoGRE sends undersized frames without padding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Jun 2019 21:31:42 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     "Steinar H. Gunderson" <steinar+kernel@...derson.no>
Cc:     Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: EoGRE sends undersized frames without padding

On Thu, May 30, 2019 at 2:08 AM Steinar H. Gunderson
<steinar+kernel@...derson.no> wrote:
>
> Hi,
>
> I'm trying to connect some VMs over EoGRE (using gretap on my side):
>
>   ip link add foo type gretap remote <remote> local <local>
>
> This works fine for large packets, but the system in the other end
> drops smaller packets, such as ARP requests and small ICMP pings.

Is the other end Linux too?

>
> After looking at the GRE packets in Wireshark, it turns out the Ethernet
> packets within the EoGRE packet is undersized (under 60 bytes), and Linux
> doesn't pad them. I haven't found anything in RFC 7637 that says anything
> about padding, so I would assume it should conform to the usual Ethernet
> padding rules, ie., pad to at least ETH_ZLEN. However, nothing in Linux' IP
> stack seems to actually do this, which means that when the packet is
> decapsulated in the other end and put on the (potentially virtual) wire,
> it gets dropped. The other system properly pads its small frames when sending
> them.


If the packet doesn't go through any real wire, it could still be accepted
by Linux even when it is smaller than ETH_ZLEN, I think. Some hardware
switches pad for ETH_ZLEN when it goes through a real wire.

So, how is your packet routed between different VM? Via a Linux bridge?


>
> Is there a way to get around this, short of looping the packets out through a
> physical wire to get the padding? Is it simply a bug? I've been testing with
> 4.19.28, but it doesn't look like git master has any changes in this area.
>

It is still too early to say it is a bug. Is this a regression?

Thanks.