netdev - Possible regression: "gre: Use inner mac length when computing tunnel length"

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]

Message-ID: <20141204141616.185b88c4@vostro>
Date:	Thu, 4 Dec 2014 14:16:16 +0200
From:	Timo Teras <timo.teras@....fi>
To:	Tom Herbert <therbert@...gle.com>,
	Alexander Duyck <alexander.h.duyck@...hat.com>,
	netdev@...r.kernel.org
Subject: Possible regression: "gre: Use inner mac length when computing
 tunnel length"

Hi,

After upgrading to latest 3.14.24 or newer, I noticed a weird TSO bug
in the "dmvpn" setup I use. And seems 3.14.23 works just fine. So the
commit 14051f0452a2c26a "gre: Use inner mac length when computing
tunnel length" would appear to be the related commit (but have not yet
tested this).

In practice what happens is that forwarding path between ethX (or vlanX)
and gre1 gets broken.

There's probably two differences to the "regular" gre tunnel case:
- it's nbma mode, meaning the gre header is inserted via slightly
  different code path
- the gre1 packets are IPsec encrypted in transport mode

As additional detail, doing "ethtool -K gre1 tso off" will workaround
the issue, so it is clearly tso issue pointing even further to the
commit in question.

Is this something the suspected patch could cause? Any suggestions
what to test more?

Thanks,
Timo

--
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