port-xen/59460: Xen netback sends data debian domU considers malicious

[Eleanor Clifford <el%assimilation2.clifford.lol@localhost>]

>Number:         59460
>Category:       port-xen
>Synopsis:       Xen netback sends data debian domU considers malicious
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 06 21:45:00 +0000 2025
>Originator:     Eleanor Clifford
>Release:        NetBSD 10.0
>Environment:
	System: NetBSD assimilation2.clifford.lol 10.0 NetBSD 10.0 (XEN3_DOM0) #0: Thu Mar 28 08:33:33 UTC 2024 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/xen/compile/XEN3_DOM0 amd64
	Architecture: x86_64
	Machine: amd64
	domU: 6.10.11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.11-1 (2024-09-22) x86_64 GNU/Linux

>Description:
	I have a system with NetBSD 10.0 as the dom0, and a number of domUs
	including debian PVH (6.10.11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.11-1 (2024-09-22) x86_64 GNU/Linux).
	Each time the debian domU is started, networking eventually fails, usually
	between a few hours and a few days after starting.

	I haven't observed similar problems on NetBSD or FreeBSD PVH domUs (but I
	assume that is because they aren't doing the same security checks). I have
	also observed issues with xen networking on an OpenBSD HVM domU, but I'm
	uncertain if that's related and it's less of an issue for me right now.

	Here is the debian domU config:

	name = "mondas"
	type="pvh"
	memory = 6144
	vcpus = 4
	kernel = "/domus/mondas/vmlinuz"
	ramdisk = "/domus/mondas/initrd.img"
	extra = "root=/dev/xvda1 init=/lib/systemd/systemd"
	vif = ['bridge=bridge0']
	disk = ['phy:/dev/root/mondas,xvda1,w'] # LVM Logical Volume

	Here are two examples of the logs from debian when networking fails:

	$ sudo journalctl -b -1 | grep 'kernel.*net'

	Jun 06 11:44:31 mondas kernel: audit: initializing netlink subsys (disabled)
	Jun 06 11:44:31 mondas kernel: xen_netfront: Initialising Xen virtual ethernet driver
	Jun 06 11:44:37 mondas kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
	Jun 06 11:44:37 mondas kernel: Initializing XFRM netlink socket
	Jun 06 15:42:22 mondas kernel: net enX0: Invalid extra type: 247
	Jun 06 15:42:22 mondas kernel: net enX0: Invalid extra type: 251
	Jun 06 15:42:22 mondas kernel: net enX0: Invalid extra type: 253
	Jun 06 15:42:22 mondas kernel: net enX0: Invalid extra type: 0
	Jun 06 15:42:22 mondas kernel: net enX0: Missing extra info
	Jun 06 15:44:36 mondas kernel: net enX0: Illegal number of responses 295

	$ sudo journalctl -b -5 | grep 'kernel.*net'

	Jun 04 11:04:28 mondas kernel: audit: initializing netlink subsys (disabled)
	Jun 04 11:04:29 mondas kernel: xen_netfront: Initialising Xen virtual ethernet driver
	Jun 04 11:04:34 mondas kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
	Jun 04 11:04:34 mondas kernel: Initializing XFRM netlink socket
	Jun 04 14:03:10 mondas kernel: net enX0: Invalid extra type: 38
	Jun 04 14:03:10 mondas kernel: net enX0: Invalid extra type: 43
	Jun 04 14:03:10 mondas kernel: net enX0: Invalid extra type: 47
	Jun 05 17:02:24 mondas kernel: net enX0: Missing extra info
	Jun 05 17:02:24 mondas kernel: net enX0: Need more slots
	Jun 05 17:03:26 mondas kernel: net enX0: Illegal number of responses 263

	When "Illegal number of responses" is hit, networking in debian stops
	working completely, until the domU is entirely restarted (I haven't been
	successful trying to only restart networking).

	I think the patch that adds this error to the linux kernel is this:

	https://patchwork.kernel.org/project/netdevbpf/patch/20210513100302.22027-8-jgross%suse.com@localhost/#24182397

	As far as I can tell, it is there to protect against malicious backends,
	and when the "Illegal number of responses" error is hit, the network
	interface is marked as broken and prevented from working.

	I am not familiar enough with the NetBSD kernel (or Xen, or the linux
	kernel) to know exactly what is going wrong, but I suppose their might be
	something wrong in sys/arch/xen/xen/xennetback_xenbus.c, perhaps
	xennetback_tx_response or xennetback_tx_check_packet?

	Of course it's also possible it's actually the Linux kernel's fault and I'm
	sending this to the wrong bug tracker...

>How-To-Repeat:
	1. Set up NetBSD 10 as dom0
	2. Set up debian domU as PVH with bridged network (as above)
	3. Wait
>Fix:
	workarounds:
	* restart domU each time
	* patch the domU kernel to remove the security check, I suppose