[SRU X/B/D] CVE-2020-1749 - tunnels over IPv6 are unencrypted when using IPsec

Thadeu Lima de Souza Cascardo cascardo at canonical.com
Wed May 6 02:23:38 UTC 2020


BugLink: https://bugs.launchpad.net/bugs/1876982

I decided to open a bug, though this is a CVE, in order to document the testing
that I did on all 3 series.

[Impact]
When tunnels are configured over IPv6 using a xfrm policy, it's ignored. That
means data will be unencrypted when it shouldn't.

[Test case]

Launch a VM with the given kernel and monitor its network link on the host with:
tcpdump -n -i virbr0 ip6 and port 4789

In the guest, set up a tunnel using an IPv6 address:
ip link add type vxlan id 5 remote fd00:cafe::2 dstport 4789

When setting the link up, observe packets being output on the host side:
ip link set vxlan0 up

Set the link down, and add a xfrm policy to block output to that given IPv6
address:
ip link set vxlan0 down
ip xfrm policy add dst fd00:cafe::2 dir out action block

Check that using ping won't work with Operation not permitted:
ping6 fd00:cafe::2
connect: Operation not permitted

Set the vxlan link up and watch that no packets appear on tcpdump:
ip link set vxlan0 up

[Regression potential]
Tunnels like VXLAN, GENEVE, etc, will stop to send. The test has shown that it
still sends at least when no xfrm policy is configured. Other potential
regressions are possible, testing those tunnel paths and failure paths would be
desirable, but hard to do.





More information about the kernel-team mailing list