Subject: Re: [vserver] Stack Clash patch for Linux-Vserver kernels
From: Corey Wright <undefined@pobox.com>
Date: Mon, 17 Jul 2017 09:11:24 -0500
Mon, 17 Jul 2017 09:11:24 -0500
On Mon, 17 Jul 2017 04:15:35 +0200
"sunebeck ." <sunebeck@gmail.com> wrote:

> Hi,
> 
> I'm sure many have heard about the Stack Clash vulnerability in the
> Linux kernel.
> 
> The only time I compiled a Linux kernel with vserver, right after
> another big vulnerability was found, I used the newest linux-source
> from Debian and applied the same available vserver patch. It worked
> back then, but I didn't do rigorous testing, I have to admit.
> 
> They say there's two things a patch needs to do:
> 
> * Fix the vulnerability
> * Not interfere with the vserver patch
> 
> How would guys you go about getting a Stack Clash proofed vserver kernel?

yeah, i was wondering how long it would take before somebody
(indirectly) asked about the 3.18 merge conflict.

stack clash was addressed in upstream 3.18.58.  that upstream version
also introduced a conflict with the linux-vserver
patch-3.18.44-vs2.3.7.5.diff patch in the ipv6 code, specifically this
commit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.18.y&id=a360eb6f74b999a7546f2542c0d6483fdbb73461

you can either:

* revert the conflicting upstream commit before applying the
  linux-vserver patch.

* apply my patch which *ignorantly* merges the two (giving preference to
  the linux-vserver code as i don't use ipv6).

* ask somebody (herbert?) to *intelligently* fix-up the vserver patch.

i've attached my patch, for purely informational purposes, and suggest
that if you use it then it might cause the end of the world.

1. obtain 3.18.58 (or later)
2. apply patch-3.18.44-vs2.3.7.5.diff
3. apply attached patch-3.18.44-58-vs2.3.7.5.diff

works for me for my usual tests (ie testme.sh, testfs.sh, start guest,
ssh into guest, update guest, stop guest, and do the same for lxc
containers), but will probably end the world for everybody else.  i'm up
to 3.18.61 in production (rolled out this weekend) and everything works
for me, but i don't use ipv6.

corey
--
undefined@pobox.com

> Sune
> 
> P.S: This list rejected my mail several time due to a SORBS listing -
> apparently, SORBS blocked Gmail(!).

i would block gmail, too, just out of principle. ;)


https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.18.y&id=a360eb6f74b999a7546f2542c0d6483fdbb73461

Give preference to Linux-Vserver patch over upstream IPv4-mapped-to-IPv6 fix.

If socket has a Linux-Vserver network context, then handle as previous,
otherwise handle as per the upstream fix.

--- a/net/ipv6/tcp_ipv6.c	2017-06-26 09:25:40.149207782 -0500
+++ b/net/ipv6/tcp_ipv6.c	2017-06-27 17:49:29.768742685 -0500
@@ -166,11 +166,17 @@ static int tcp_v6_connect(struct sock *s
 	 */
 
 	if (ipv6_addr_any(&usin->sin6_addr)) {
-		if (ipv6_addr_v4mapped(&sk->sk_v6_rcv_saddr))
-			ipv6_addr_set_v4mapped(htonl(INADDR_LOOPBACK),
-					       &usin->sin6_addr);
+		struct nx_info *nxi =  sk->sk_nx_info;
+
+		if (nxi && nx_info_has_v6(nxi))
+			/* FIXME: remap lback? */
+			usin->sin6_addr = nxi->v6.ip;
 		else
-			usin->sin6_addr = in6addr_loopback;
+			if (ipv6_addr_v4mapped(&sk->sk_v6_rcv_saddr))
+				ipv6_addr_set_v4mapped(htonl(INADDR_LOOPBACK),
+						       &usin->sin6_addr);
+			else
+				usin->sin6_addr = in6addr_loopback;
 	}
 
 	addr_type = ipv6_addr_type(&usin->sin6_addr);