Linux v3.12-rc1-250-g7b9e3a6

4 files changed, 5 insertions, 301 deletions

diff --git a/kernel.spec b/kernel.spec
index b12744fc4..cd236a5b2 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -95,7 +95,7 @@ Summary: The Linux kernel
 # The rc snapshot level
 %define rcrev 1
 # The git snapshot level
-%define gitrev 3
+%define gitrev 4
 # Set rpm version accordingly
 %define rpmversion 3.%{upstream_sublevel}.0
 %endif
@@ -754,12 +754,6 @@ Patch25032: cve-2013-2147-ciss-info-leak.patch
 
 Patch25047: drm-radeon-Disable-writeback-by-default-on-ppc.patch
 
-#CVE-2013-4343 rhbz 1007733 1007741
-Patch25100: tuntap-correctly-handle-error-in-tun_set_iff.patch
-
-#CVE-2013-4350 rhbz 1007872 1007903
-Patch25102: net-sctp-fix-ipv6-ipsec-encryption-bug-in-sctp_v6_xmit.patch
-
 #CVE-2013-4345 rhbz 1007690 1009136
 Patch25104: ansi_cprng-Fix-off-by-one-error-in-non-block-size-request.patch
 
@@ -1481,12 +1475,6 @@ ApplyPatch drm-radeon-Disable-writeback-by-default-on-ppc.patch
 
 ApplyPatch fix-arm-btrfs-build.patch
 
-#CVE-2013-4343 rhbz 1007733 1007741
-ApplyPatch tuntap-correctly-handle-error-in-tun_set_iff.patch
-
-#CVE-2013-4350 rhbz 1007872 1007903
-ApplyPatch net-sctp-fix-ipv6-ipsec-encryption-bug-in-sctp_v6_xmit.patch
-
 #CVE-2013-4345 rhbz 1007690 1009136
 ApplyPatch ansi_cprng-Fix-off-by-one-error-in-non-block-size-request.patch
 
@@ -2294,6 +2282,9 @@ fi
 #                                    ||----w |
 #                                    ||     ||
 %changelog
+* Fri Sep 20 2013 Josh Boyer <jwboyer@fedoraproject.org> - 3.12.0-0.rc1.git4.1
+- Linux v3.12-rc1-250-g7b9e3a6
+
 * Thu Sep 19 2013 Josh Boyer <jwboyer@fedoraproject.org> - 3.12.0-0.rc1.git3.1
 - Linux v3.12-rc1-101-ged24fee
 
diff --git a/net-sctp-fix-ipv6-ipsec-encryption-bug-in-sctp_v6_xmit.patch b/net-sctp-fix-ipv6-ipsec-encryption-bug-in-sctp_v6_xmit.patch
deleted file mode 100644
index 671ee98db..000000000
--- a/net-sctp-fix-ipv6-ipsec-encryption-bug-in-sctp_v6_xmit.patch
+++ /dev/null
@@ -1,186 +0,0 @@
-From 95ee62083cb6453e056562d91f597552021e6ae7 Mon Sep 17 00:00:00 2001
-From: Daniel Borkmann <dborkman@redhat.com>
-Date: Wed, 11 Sep 2013 14:58:36 +0000
-Subject: net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit
-
-Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
-being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
-does not seem to have the desired effect:
-
-SCTP + IPv4:
-
-  22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
-    192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
-  22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
-    192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):
-
-SCTP + IPv6:
-
-  22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
-    fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
-    1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]
-
-Moreover, Alan says:
-
-  This problem was seen with both Racoon and Racoon2. Other people have seen
-  this with OpenSwan. When IPsec is configured to encrypt all upper layer
-  protocols the SCTP connection does not initialize. After using Wireshark to
-  follow packets, this is because the SCTP packet leaves Box A unencrypted and
-  Box B believes all upper layer protocols are to be encrypted so it drops
-  this packet, causing the SCTP connection to fail to initialize. When IPsec
-  is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.
-
-In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
-string on the other end, results in cleartext on the wire where SCTP eventually
-does not report any errors, thus in the latter case that Alan reports, the
-non-paranoid user might think he's communicating over an encrypted transport on
-SCTP although he's not (tcpdump ... -X):
-
-  ...
-  0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000  ]p.......}.l....
-  0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000  ....plaintext...
-
-Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
-receiver side. Initial follow-up analysis from Alan's bug report was done by
-Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.
-
-SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
-This has the implication that it probably never really got updated along with
-changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.
-
-SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
-a call to inet6_csk_xmit() would solve this problem, but result in unecessary
-route lookups, let us just use the cached flowi6 instead that we got through
-sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
-we do the route lookup / flow caching in sctp_transport_route(), hold it in
-tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
-sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
-of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
-instead to get the correct source routed dst entry, which we assign to the skb.
-
-Also source address routing example from 625034113 ("sctp: fix sctp to work with
-ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
-it is actually 'recommended' to not use that anyway due to traffic amplification [1].
-So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
-we overwrite the flow destination here, the lower IPv6 layer will be unable to
-put the correct destination address into IP header, as routing header is added in
-ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
-result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
-the wire with this patch it now looks like:
-
-SCTP + IPv6:
-
-  08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
-    AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
-  08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
-    AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296
-
-This fixes Kernel Bugzilla 24412. This security issue seems to be present since
-2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
-its fun with that. lksctp-tools IPv6 regression test suite passes as well with
-this patch.
-
- [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
-
-Reported-by: Alan Chester <alan.chester@tekelec.com>
-Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
-Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
-Cc: Steffen Klassert <steffen.klassert@secunet.com>
-Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
-Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-Signed-off-by: David S. Miller <davem@davemloft.net>
----
-diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
-index da613ce..4f52e2c 100644
---- a/net/sctp/ipv6.c
-+++ b/net/sctp/ipv6.c
-@@ -204,44 +204,23 @@ out:
- 		in6_dev_put(idev);
- }
- 
--/* Based on tcp_v6_xmit() in tcp_ipv6.c. */
- static int sctp_v6_xmit(struct sk_buff *skb, struct sctp_transport *transport)
- {
- 	struct sock *sk = skb->sk;
- 	struct ipv6_pinfo *np = inet6_sk(sk);
--	struct flowi6 fl6;
--
--	memset(&fl6, 0, sizeof(fl6));
--
--	fl6.flowi6_proto = sk->sk_protocol;
--
--	/* Fill in the dest address from the route entry passed with the skb
--	 * and the source address from the transport.
--	 */
--	fl6.daddr = transport->ipaddr.v6.sin6_addr;
--	fl6.saddr = transport->saddr.v6.sin6_addr;
--
--	fl6.flowlabel = np->flow_label;
--	IP6_ECN_flow_xmit(sk, fl6.flowlabel);
--	if (ipv6_addr_type(&fl6.saddr) & IPV6_ADDR_LINKLOCAL)
--		fl6.flowi6_oif = transport->saddr.v6.sin6_scope_id;
--	else
--		fl6.flowi6_oif = sk->sk_bound_dev_if;
--
--	if (np->opt && np->opt->srcrt) {
--		struct rt0_hdr *rt0 = (struct rt0_hdr *) np->opt->srcrt;
--		fl6.daddr = *rt0->addr;
--	}
-+	struct flowi6 *fl6 = &transport->fl.u.ip6;
- 
- 	pr_debug("%s: skb:%p, len:%d, src:%pI6 dst:%pI6\n", __func__, skb,
--		 skb->len, &fl6.saddr, &fl6.daddr);
-+		 skb->len, &fl6->saddr, &fl6->daddr);
- 
--	SCTP_INC_STATS(sock_net(sk), SCTP_MIB_OUTSCTPPACKS);
-+	IP6_ECN_flow_xmit(sk, fl6->flowlabel);
- 
- 	if (!(transport->param_flags & SPP_PMTUD_ENABLE))
- 		skb->local_df = 1;
- 
--	return ip6_xmit(sk, skb, &fl6, np->opt, np->tclass);
-+	SCTP_INC_STATS(sock_net(sk), SCTP_MIB_OUTSCTPPACKS);
-+
-+	return ip6_xmit(sk, skb, fl6, np->opt, np->tclass);
- }
- 
- /* Returns the dst cache entry for the given source and destination ip
-@@ -254,10 +233,12 @@ static void sctp_v6_get_dst(struct sctp_transport *t, union sctp_addr *saddr,
- 	struct dst_entry *dst = NULL;
- 	struct flowi6 *fl6 = &fl->u.ip6;
- 	struct sctp_bind_addr *bp;
-+	struct ipv6_pinfo *np = inet6_sk(sk);
- 	struct sctp_sockaddr_entry *laddr;
- 	union sctp_addr *baddr = NULL;
- 	union sctp_addr *daddr = &t->ipaddr;
- 	union sctp_addr dst_saddr;
-+	struct in6_addr *final_p, final;
- 	__u8 matchlen = 0;
- 	__u8 bmatchlen;
- 	sctp_scope_t scope;
-@@ -281,7 +262,8 @@ static void sctp_v6_get_dst(struct sctp_transport *t, union sctp_addr *saddr,
- 		pr_debug("src=%pI6 - ", &fl6->saddr);
- 	}
- 
--	dst = ip6_dst_lookup_flow(sk, fl6, NULL, false);
-+	final_p = fl6_update_dst(fl6, np->opt, &final);
-+	dst = ip6_dst_lookup_flow(sk, fl6, final_p, false);
- 	if (!asoc || saddr)
- 		goto out;
- 
-@@ -333,10 +315,12 @@ static void sctp_v6_get_dst(struct sctp_transport *t, union sctp_addr *saddr,
- 		}
- 	}
- 	rcu_read_unlock();
-+
- 	if (baddr) {
- 		fl6->saddr = baddr->v6.sin6_addr;
- 		fl6->fl6_sport = baddr->v6.sin6_port;
--		dst = ip6_dst_lookup_flow(sk, fl6, NULL, false);
-+		final_p = fl6_update_dst(fl6, np->opt, &final);
-+		dst = ip6_dst_lookup_flow(sk, fl6, final_p, false);
- 	}
- 
- out:
---
-cgit v0.9.2
diff --git a/sources b/sources
index ceb58f2cc..8af22d2a8 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,3 @@
 fea363551ff45fbe4cb88497b863b261  linux-3.11.tar.xz
 9e56aa52fa00092499ba943557f197eb  patch-3.12-rc1.xz
-1b5ff7593dac2d71b40af88473b2ab49  patch-3.12-rc1-git3.xz
+a0b91a6f9fdb04a72d0e604476baa9af  patch-3.12-rc1-git4.xz
diff --git a/tuntap-correctly-handle-error-in-tun_set_iff.patch b/tuntap-correctly-handle-error-in-tun_set_iff.patch
deleted file mode 100644
index dae714853..000000000
--- a/tuntap-correctly-handle-error-in-tun_set_iff.patch
+++ /dev/null
@@ -1,101 +0,0 @@
-                                                                                                                                                                                                                                                               
-Delivered-To: jwboyer@gmail.com
-Received: by 10.76.168.104 with SMTP id zv8csp8822oab;
-        Wed, 11 Sep 2013 03:26:37 -0700 (PDT)
-X-Received: by 10.68.202.130 with SMTP id ki2mr879977pbc.43.1378895196744;
-        Wed, 11 Sep 2013 03:26:36 -0700 (PDT)
-Return-Path: <linux-kernel-owner@vger.kernel.org>
-Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
-        by mx.google.com with ESMTP id jx3si1809697pbc.204.1969.12.31.16.00.00;
-        Wed, 11 Sep 2013 03:26:36 -0700 (PDT)
-Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
-Authentication-Results: mx.google.com;
-       spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=linux-kernel-owner@vger.kernel.org
-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-	id S1753006Ab3IKKVh (ORCPT <rfc822;paul.gortmaker@gmail.com>
-	+ 99 others); Wed, 11 Sep 2013 06:21:37 -0400
-Received: from mx1.redhat.com ([209.132.183.28]:54338 "EHLO mx1.redhat.com"
-	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
-	id S1751208Ab3IKKVg (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
-	Wed, 11 Sep 2013 06:21:36 -0400
-Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
-	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8BALYs3006442
-	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
-	Wed, 11 Sep 2013 06:21:34 -0400
-Received: from amd-6168-8-1.englab.nay.redhat.com (amd-6168-8-1.englab.nay.redhat.com [10.66.104.52])
-	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8BALVUV014234;
-	Wed, 11 Sep 2013 06:21:32 -0400
-From:	Jason Wang <jasowang@redhat.com>
-To:	davem@davemloft.net, mst@redhat.com, netdev@vger.kernel.org,
-	linux-kernel@vger.kernel.org
-Cc:	wannes.rombouts@epitech.eu, Jason Wang <jasowang@redhat.com>
-Subject: [PATCH net V2] tuntap: correctly handle error in tun_set_iff()
-Date:	Wed, 11 Sep 2013 18:09:48 +0800
-Message-Id: <1378894188-8015-1-git-send-email-jasowang@redhat.com>
-X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
-Sender:	linux-kernel-owner@vger.kernel.org
-Precedence: bulk
-List-ID: <linux-kernel.vger.kernel.org>
-X-Mailing-List:	linux-kernel@vger.kernel.org
-
-Commit c8d68e6be1c3b242f1c598595830890b65cea64a
-(tuntap: multiqueue support) only call free_netdev() on error in
-tun_set_iff(). This causes several issues:
-
-- memory of tun security were leaked
-- use after free since the flow gc timer was not deleted and the tfile
-  were not detached
-
-This patch solves the above issues.
-
-Reported-by: Wannes Rombouts <wannes.rombouts@epitech.eu>
-Cc: Michael S. Tsirkin <mst@redhat.com>
-Signed-off-by: Jason Wang <jasowang@redhat.com>
----
-- Changes from V1: shift 1 space for label err_free_netdev and keep
-  commit log under 70 chars per line.
-- The patch were needed for stable kernel 3.8+.
----
- drivers/net/tun.c |   11 ++++++++---
- 1 files changed, 8 insertions(+), 3 deletions(-)
-
-diff --git a/drivers/net/tun.c b/drivers/net/tun.c
-index a639de8..807815f 100644
---- a/drivers/net/tun.c
-+++ b/drivers/net/tun.c
-@@ -1641,11 +1641,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
- 		INIT_LIST_HEAD(&tun->disabled);
- 		err = tun_attach(tun, file, false);
- 		if (err < 0)
--			goto err_free_dev;
-+			goto err_free_flow;
- 
- 		err = register_netdevice(tun->dev);
- 		if (err < 0)
--			goto err_free_dev;
-+			goto err_detach;
- 
- 		if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
- 		    device_create_file(&tun->dev->dev, &dev_attr_owner) ||
-@@ -1689,7 +1689,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
- 	strcpy(ifr->ifr_name, tun->dev->name);
- 	return 0;
- 
-- err_free_dev:
-+err_detach:
-+	tun_detach_all(dev);
-+err_free_flow:
-+	tun_flow_uninit(tun);
-+	security_tun_dev_free_security(tun->security);
-+err_free_dev:
- 	free_netdev(dev);
- 	return err;
- }
--- 
-1.7.1
-
---
-To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
-Please read the FAQ at  http://www.tux.org/lkml/