netdev - macvtap performs IP defragmentation, causing MTU problems for virtual machines

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: Sat, 30 Sep 2023 18:00:20 +0200
From: Henrik Lindström <lindstrom515@...il.com>
To: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: macvtap performs IP defragmentation, causing MTU problems for virtual machines

Hi,

We are trying to receive fragmented multicast traffic on a qemu/kvm VM
using a macvtap NIC (e1000e model).
Even though the traffic is properly fragmented by the sender, it's
never received by the VM.

The reason seems to be that the macvlan driver performs IP
defragmentation for multicast traffic, causing e1001e to drop it for
being too big.
It works fine with a virtio NIC instead of e1000e, but that's not an
option for us.

I found this old thread describing why macvlan does this:
https://lore.kernel.org/netdev/4E8C89EE.3090600@candelatech.com/
Interestingly, the problem described in that thread seems to be more
general than macvlans, and i can still reproduce it by simply having
multiple physical interfaces.
So it looks like macvlans are being special-cased right now, as a
workaround for a more general defragmentation problem?

A fix for our issue is to simply remove the `ip_check_defrag` call
from `macvlan_handle_frame`, but that regresses the other issue..
I'm not sure what a proper fix would look like, but it feels a bit
unexpected that macvtaps would perform IP defragmentation.

Thanks,
Henrik