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:	Mon, 07 Apr 2014 18:04:42 +0200
From:	Tobias Brunner <tobias@...ongswan.org>
To:	Florian Westphal <fw@...len.de>
CC:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Marcelo Ricardo Leitner <mleitner@...hat.com>
Subject: Problems with fragments since gso skb forwarding changes in virtual
 environment

Hi Florian et al,

We noticed a problem with fragmented packets in the KVM/libvirt-based
strongSwan integration test environment [1] with guest kernels that
include the following commit:

	net: ip, ipv6: handle gso skbs in forwarding path
	fe6cc55f3a9a053482a76f5a6b2257cee51b4663

The network topology in test scenarios that trigger the problem is as
follows:

	Host A - br1 - Router R - br2 - Host B

Where the two hosts and the router are virtual guests connected via
bridges all created via libvirt (see [2] for the XML config files).  The
guest's network interfaces all use virtio.

If the router runs with a kernel that includes the commit above, packets
sent from A to B that exceed the MTU (1500 in this case) will be split
into fragments when leaving R.  These fragment skbs get defragmented by
the host kernel's nf_defrag_ipv4 module while being forwarded on br2.

This poses a problem.  Because the fragment skbs are not GSO, neither is
the defragmented skb.  Hence the packets are dropped just before leaving
the bridge, as is_skb_forwardable() will return false unless a too large
skb is actually GSO (this is the same for older host kernels, where the
check is directly done in br_forward.c).

Without the commit, and between A and R even with it (because it only
affects forwarding), the skbs are GSO throughout and transmitted from A
to B without ever actually being fragmented.

Any ideas how to fix this properly?  That is, without just reverting
parts of your commit for our guest kernels.

Regards,
Tobias

[1] http://wiki.strongswan.org/projects/strongswan/wiki/TestingEnvironment
[2] http://git.strongswan.org/?p=strongswan.git;a=tree;f=testing/config/kvm
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ