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

[Khaled Elmously]

Applied to X.

The B/D patch was already present in B/D by way of stable updates.

Thanks


On 2019-08-02 07:14:09 , Connor Kuehl wrote:
> https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-10638.html
> 
> 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.
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team