Issue metadata
Sign in to add a comment
|
CVE-2017-1000112 CrOS: Vulnerability reported in Linux kernel |
||||||||||||||||||||||
Issue descriptionVOMIT (go/vomit) has received an external vulnerability report for the Linux kernel. Advisory: CVE-2017-1000112 Details: http://vomit.googleplex.com/advisory?id=CVE/CVE-2017-1000112 CVSS severity score: 6.9/10.0 Description: Linux kernel: Exploitable memory corruption due to UFO to non-UFO path switch. When building a UFO packet with MSG_MORE __ip_append_data() calls ip_ufo_append_data() to append. However in between two send() calls, the append path can be switched from UFO to non-UFO one, which leads to a memory corruption. In case UFO packet lengths exceeds MTU, copy = maxfraglen - skb->len becomes negative on the non-UFO path and the branch to allocate new skb is taken. This triggers fragmentation and computation of fraggap = skb_prev->len - maxfraglen. Fraggap can exceed MTU, causing copy = datalen - transhdrlen - fraggap to become negative. Subsequently skb_copy_and_csum_bits() writes out-of-bounds. A similar issue is present in IPv6 code. The bug was introduced in e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") on Oct 18 2005. This bug was filed by http://go/vomit Please contact us at vomit-team@google.com if you need any assistance.
,
Nov 2 2017
,
Nov 2 2017
Looking at the advisory, the fix seems to be this? https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa
,
Nov 2 2017
#3: Good find; you are correct. Somehow I missed that. It is already applied to chromeos-4.4 (with the merge to v4.4.86), so we'll only need it in older kernels.
,
Nov 2 2017
Fixed in chromeos-4.4/M-63. WontFix for chromeos-3.18 and earlier kernels: There are various problems in the networking code of chromeos-3.18 which have not been fixed (but have been fixed in the 3.18 stable release). Trying to fix just one of them would not add much if any value and is risky due to conflicts. Leaving open in case Lakitu needs to have the fix applied to M-62 and/or M-61.
,
Nov 2 2017
Yes, lakitu would want this in 62 and 61.
,
Nov 2 2017
Requesting merge to R61 and R62 per #6.
,
Nov 3 2017
,
Nov 3 2017
,
Nov 4 2017
,
Nov 7 2017
I'll take this and work on the 61 merge.
,
Nov 8 2017
,
Nov 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5e02a24a574ecbd1f39fe370475c399e1f93d131 commit 5e02a24a574ecbd1f39fe370475c399e1f93d131 Author: Willem de Bruijn <willemb@google.com> Date: Wed Nov 08 22:45:24 2017 BACKPORT: udp: consistently apply ufo or fragmentation [ Upstream commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa ] When iteratively building a UDP datagram with MSG_MORE and that datagram exceeds MTU, consistently choose UFO or fragmentation. Once skb_is_gso, always apply ufo. Conversely, once a datagram is split across multiple skbs, do not consider ufo. Sendpage already maintains the first invariant, only add the second. IPv6 does not have a sendpage implementation to modify. A gso skb must have a partial checksum, do not follow sk_no_check_tx in udp_send_skb. Found by syzkaller. The upstream patch had a merge conflict as below and I chose upstream, hence BACKPORT. conflict in net/ipv6/ip6_output.c: ++<<<<<<< HEAD + if (((length > mtu) || + (skb && skb_is_gso(skb))) && ++======= + if ((skb && skb_is_gso(skb)) || + (((length + fragheaderlen) > mtu) && + (skb_queue_len(queue) <= 1) && ++>>>>>>> 938990d2433c... udp: consistently apply ufo or fragmentation BUG= chromium:780783 TEST=trybot Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 938990d2433cdecd225e1ab54a442b3ffdce1f87) Signed-off-by: Daniel Wang <wonderfly@google.com> Change-Id: Iacb716f20d9297119736c429d5b442ea309ed500 Reviewed-on: https://chromium-review.googlesource.com/758495 Tested-by: Daniel Wang <wonderfly@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Commit-Queue: Daniel Wang <wonderfly@google.com> [modify] https://crrev.com/5e02a24a574ecbd1f39fe370475c399e1f93d131/net/ipv4/ip_output.c [modify] https://crrev.com/5e02a24a574ecbd1f39fe370475c399e1f93d131/net/ipv4/udp.c [modify] https://crrev.com/5e02a24a574ecbd1f39fe370475c399e1f93d131/net/ipv6/ip6_output.c
,
Nov 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b3813349f32f4d6b2e2bd58c5a8a9abcfa508c49 commit b3813349f32f4d6b2e2bd58c5a8a9abcfa508c49 Author: Willem de Bruijn <willemb@google.com> Date: Wed Nov 08 22:49:57 2017 UPSTREAM: udp: consistently apply ufo or fragmentation [ Upstream commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa ] When iteratively building a UDP datagram with MSG_MORE and that datagram exceeds MTU, consistently choose UFO or fragmentation. Once skb_is_gso, always apply ufo. Conversely, once a datagram is split across multiple skbs, do not consider ufo. Sendpage already maintains the first invariant, only add the second. IPv6 does not have a sendpage implementation to modify. A gso skb must have a partial checksum, do not follow sk_no_check_tx in udp_send_skb. Found by syzkaller. BUG= chromium:780783 TEST=trybot Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach") Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 938990d2433cdecd225e1ab54a442b3ffdce1f87) Signed-off-by: Daniel Wang <wonderfly@google.com> Change-Id: I1809e6fb063d047622a6e34f7b0717b2195cfb1c Reviewed-on: https://chromium-review.googlesource.com/759104 Tested-by: Daniel Wang <wonderfly@google.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Commit-Queue: Daniel Wang <wonderfly@google.com> [modify] https://crrev.com/b3813349f32f4d6b2e2bd58c5a8a9abcfa508c49/net/ipv4/ip_output.c [modify] https://crrev.com/b3813349f32f4d6b2e2bd58c5a8a9abcfa508c49/net/ipv4/udp.c [modify] https://crrev.com/b3813349f32f4d6b2e2bd58c5a8a9abcfa508c49/net/ipv6/ip6_output.c
,
Nov 8 2017
,
Nov 9 2017
,
Nov 13 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 17 2017
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 15 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 27 2018
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by groeck@chromium.org
, Nov 2 2017Owner: groeck@chromium.org
Status: Assigned (was: Untriaged)
Upstream 988cf74deb45 ("inet: Stop generating UFO packets.") should fix the problem. The problem may potentially affect VMs.