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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 8 Apr 2014 17:36:19 +0200 From: Florian Westphal <fw@...len.de> To: Florian Westphal <fw@...len.de> Cc: Tobias Brunner <tobias@...ongswan.org>, netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Herbert Xu <herbert@...dor.apana.org.au>, Marcelo Ricardo Leitner <mleitner@...hat.com> Subject: Re: Problems with fragments since gso skb forwarding changes in virtual environment Florian Westphal <fw@...len.de> wrote: [ cc'd Eric ] > Thanks for clarifying. In this case there is another problem as well as > no fragments should be generated in the forwarding path if the outgoing mtu > is not reduced. > > Most likely a problem with udp gso + skb_gso_network_seglen(). Indeed, the problem is here: unsigned int skb_gso_transport_seglen(const struct sk_buff *skb) { const struct skb_shared_info *shinfo = skb_shinfo(skb); unsigned int hdr_len; if (likely(shinfo->gso_type & (SKB_GSO_TCPV4 | SKB_GSO_TCPV6))) hdr_len = tcp_hdrlen(skb); else hdr_len = sizeof(struct udphdr); return hdr_len + shinfo->gso_size; } For large GSO UDP packet received via virtio shinfo->gso_size is 1480 (mtu 1500). Thus skb_gso_transport_seglen() claims transport seglen of 1488 which makes fwd path think we're trying to send 1508 byte segments. I am not familiar with UFO; setting hdr_len = 0 in else clause makes things work for me. I'll see if the sizeof(struct udphdr) is bogus for ufo or if ->gso_size is wrong. -- 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