An issue was found in the Linux kernel ipv6 implementation of GRE tunnels which allows a remote attacker to trigger an out-of-bounds access. At this time we understand no trust barrier has been crossed and there is no security implications in this flaw. References: http://seclists.org/oss-sec/2017/q1/323 Upstream patch: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=7892032cfe67f4bde6fc2ee967e45a8fbaf33756
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1419851]
Logic behind my reasoning: I'm sure that people will want to know why this bug wont be fixed. Below is my understanding of the issue, please correct me if you can see a flaw in my reasoning. The flaw is in the following expression *(((__be32 *)p) + (grehlen / 4) - 1) which creates a key at accesses data at approximately 40 bytes after the expected value, this could be a remote attacker controlled value. This value was the key offset into the GRE header. The kernel function ip6gre_tunnel_lookup used this key offset to make a hash, in which all tunnels are searched for a matching tunnel to report errors. This function can possibly return null (the likely case) or if the attacker was able to create a situation in which they were able to match an existing tunnel. t = ip6gre_tunnel_lookup(skb->dev, &ipv6h->daddr, &ipv6h->saddr, flags & GRE_KEY ? *(((__be32 *)p) + (grehlen / 4) - 1) : 0, p[1]); if (t == NULL) return; The t value could be assigned to an existing tunnel. This functions main task is to log the error conditions on the tunnel that has been matched. The ip6gre_err function goes on to use "t" as parts of warnings to be printed to the kernel log, depending on the error type. An example of this is: net_warn_ratelimited("%s: Path to destination invalid or inactive!\n", t->parms.name); This would incorrectly attribute the log error that generated the issue to the incorrect tunnel. There is only one policy decision made, in the case of the ICMPV6 packet was too large. case ICMPV6_PKT_TOOBIG: mtu = info - offset; if (mtu < IPV6_MIN_MTU) mtu = IPV6_MIN_MTU; t->dev->mtu = mtu; break; } No further work is done to either free this tunnel or modify this matched tunnel. At this time we do not believe there is a denial of service, memory leak, privilege escalation or trust barrier crossed. The kernel may attribute errors in system logs to the wrong tunnel. If you believe this is in error and have evidence or thoughts to the contrary please contact the Red Hat Product Security Team via secalert'
Statement: Red Hat Enterprise Linux 5 and 6 are not affected as they do not include this code. Red Hat Enterprise Linux 7, MRG and realtime kernels contain the code, but are not affected. At this time we do not believe there is a denial of service, memory leak, privilege escalation or trust barrier crossed. The kernel may attribute errors in system logs to the wrong tunnel. If you believe this is in error and have evidence or thoughts to the contrary please contact Red Hat Security Team.
kernel-4.9.9-100.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.