Date: Sat, 2 Jul 2011 17:48:56 -0700 From: Jack Vogel <jfvogel@gmail.com> To: Colin Percival <cperciva@freebsd.org> Cc: Jack F Vogel <jfv@freebsd.org>, freebsd-net@freebsd.org Subject: Re: integer overflow in TCP LRO Message-ID: <CAFOYbc=%2Bhrb7SrsW-tPZZQbq2zMfZ=rp5k_AGWHZ_WEPEmtiVQ@mail.gmail.com> In-Reply-To: <4E0F8C95.50507@freebsd.org> References: <4E0F8C95.50507@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Looks good to me, good work! Jack On Sat, Jul 2, 2011 at 2:24 PM, Colin Percival <cperciva@freebsd.org> wrote: > Hi all, > > In tcp_lro_rx it's possible for lro->len to exceed 65536, resulting in an > integer overflow and 65536 bytes of TCP "packet loss" when tcp_lro_flush > stuffs lro->len back into an IP header. > > It's clear that an attempt was made to avoid overflow > 339: /* flush packet if required */ > 340: device_mtu = cntl->ifp->if_mtu; > 341: if (lro->len > (65535 - device_mtu)) { > but this doesn't work because incoming "packets" can be larger than > device_mtu bytes if LRO is turned on. > > I've attached a patch which fixes this and improves Linux->FreeBSD network > performance on EC2 cluster compute nodes from 13 Mbps to 4100 Mbps... any > objections to me committing this? > > -- > Colin Percival > Security Officer, FreeBSD | freebsd.org | The power to serve > Founder / author, Tarsnap | tarsnap.com | Online backups for the truly > paranoid >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbc=%2Bhrb7SrsW-tPZZQbq2zMfZ=rp5k_AGWHZ_WEPEmtiVQ>