ACK: [SRU][X/B/D][CVE-2019-10638] inet: switch IP ID generator to siphash
kleber.souza at canonical.com
Mon Aug 12 14:49:27 UTC 2019
On 8/2/19 4:14 PM, Connor Kuehl wrote:
> 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.
Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
More information about the kernel-team