netdev - Linux 4.14 - regression: broken tun/tap / bridge network with virtio

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-next>] [day] [month] [year] [list]

Date:   Sun, 26 Nov 2017 15:17:15 +0100
From:   Andreas Hartmann <andihartmann@...19freenet.de>
To:     john.fastabend@...il.com, netdev@...r.kernel.org
Subject: Linux 4.14 - regression: broken tun/tap / bridge network with virtio
 - bisected

Hello!

Since Linux 4.14 (running as host), the virtual network based on bridge
and tun/tap-devices is partly broken. Linux 4.13.x or earlier works
perfectly.

Given is the following architecture on host:

VM1 -> tun/tap -> br1
VM2 -> tun/tap -> br0 / br1
VM3 -> tun/tap -> br0

Example network configuration of the VMs:

    <interface type='bridge'>
      <mac address='...'/>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>

Host is connected through br1.

VM2 is the router between two different networks provided by br1 and br0.

VM3 can be reached by the host via ssh through the router.
There are some more VMs in the network provided by br0 - e.g. VM4.

Mostly all VMs are Centos 7 / 64bit (Linux 3.10.x) VMs provided by
kvm_amd. VM1 uses Linux 4.4.x.

Now, VM1 sends a UDP IPv4 package (it's the first radius message from
hostapd during initialization of a EAP-TLS handshake with a WLAN client
- Access Request) to VM3. This package is answered by VM3 (Access
Challenge) and received by VM1.

Next, VM1 sends the second Access Request. I'm not sure, if this package
is still received by VM3 or not. But this is sure: VM1 never gets any
answer and the connection to VM3 is now *completely dead*. It isn't even
possible to reach VM3 by ssh any more.

There aren't any log messages - neither on the host, nor on the VM.
Other VMs aren't affected.

Bisecting the problem leads to this patch:

2ddf71e23cc246e95af72a6deed67b4a50a7b81c
net: add notifier hooks for devmap bpf map

It turns out, that the problem can be worked around by using e1000 as VM
interface instead of virtio for VM1 and 3:

    <interface type='bridge'>
      <mac address='52:54:00:15:ac:42'/>
      <source bridge='br0'/>
      <!-- <model type='virtio'/> -->
      <model type='e1000'/>
    </interface>

Would it be possible to fix this problem to get it working again with
virtio? Do you need some more information? Feel free to ask!

Thanks,
Andreas