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>