[SRU][X/B/D][CVE-2019-10638] inet: switch IP ID generator to siphash

Connor Kuehl connor.kuehl at canonical.com
Fri Aug 2 14:14:09 UTC 2019


>From the link above:

"In the Linux kernel before 5.1.7, a device can be tracked by an attacker
using the IP ID values the kernel produces for connection-less protocols
(e.g., UDP and ICMP). When such traffic is sent to multiple destination IP
addresses, it is possible to obtain hash collisions (of indices to the
counter array) and thereby obtain the hashing key (via enumeration). An
attack may be conducted by hosting a crafted web page that uses WebRTC or
gQUIC to force UDP traffic to attacker-controlled IP addresses."

The CVE analysis linked above also identifies another upstream commit required
to address this CVE: 355b98553789 "netns: provide pure entropy for net_hash_mix()"
This commit has already been applied to the affected releases from our upstream
sync process:

 * Xenial update: 4.4.179 upstream stable release
   - https://bugs.launchpad.net/bugs/1828420
 * Bionic update: upstream stable patchset 2019-07-26
   - https://bugs.launchpad.net/bugs/1838116
 * Disco update: 5.0.8 upstream stable release
   - https://bugs.launchpad.net/bugs/1828415

This patch was a clean cherry pick for Bionic and Disco.

For Xenial, I had to pull in the siphash module (can't switch to it if it doesn't
exist) which required minor offset adjustments for high-traffic commit areas like
the Kconfig and Makefile. I set the test hash config option to 'n' to remain
consistent with the other releases. 'N' is also the default suggested value for
the module. Since the other files were new, they didn't require any attention.

The actual patch for this CVE required a minor adjustment to the way it "returns" the
'id' value since it modifies ipv6_proxy_select_ident which has a void return type. The
patch context expects the function signature to be updated to return the value instead
of store it in the skbuf, but this change to the signature doesn't happen until upstream
commit 0c19f846d582 "net: accept UFO datagrams from tuntap and packet" -- I felt the
simplicity of the backport was more justifiable than cherry-picking another patch (and its
possible pre-requisites / other consequences) for a clean cherry-pick.

More information about the kernel-team mailing list