]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 30 Mar 2017 07:51:33 +0000 (09:51 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 30 Mar 2017 07:51:33 +0000 (09:51 +0200)
added patches:
xfrm-policy-init-locks-early.patch
xfrm_user-validate-xfrm_msg_newae-incoming-esn-size-harder.patch
xfrm_user-validate-xfrm_msg_newae-xfrma_replay_esn_val-replay_window.patch

queue-4.4/xfrm-policy-init-locks-early.patch [new file with mode: 0644]
queue-4.4/xfrm_user-validate-xfrm_msg_newae-incoming-esn-size-harder.patch [new file with mode: 0644]
queue-4.4/xfrm_user-validate-xfrm_msg_newae-xfrma_replay_esn_val-replay_window.patch [new file with mode: 0644]

diff --git a/queue-4.4/xfrm-policy-init-locks-early.patch b/queue-4.4/xfrm-policy-init-locks-early.patch
new file mode 100644 (file)
index 0000000..c624a44
--- /dev/null
@@ -0,0 +1,66 @@
+From c282222a45cb9503cbfbebfdb60491f06ae84b49 Mon Sep 17 00:00:00 2001
+From: Florian Westphal <fw@strlen.de>
+Date: Wed, 8 Feb 2017 11:52:29 +0100
+Subject: xfrm: policy: init locks early
+
+From: Florian Westphal <fw@strlen.de>
+
+commit c282222a45cb9503cbfbebfdb60491f06ae84b49 upstream.
+
+Dmitry reports following splat:
+ INFO: trying to register non-static key.
+ the code is fine but needs lockdep annotation.
+ turning off the locking correctness validator.
+ CPU: 0 PID: 13059 Comm: syz-executor1 Not tainted 4.10.0-rc7-next-20170207 #1
+[..]
+ spin_lock_bh include/linux/spinlock.h:304 [inline]
+ xfrm_policy_flush+0x32/0x470 net/xfrm/xfrm_policy.c:963
+ xfrm_policy_fini+0xbf/0x560 net/xfrm/xfrm_policy.c:3041
+ xfrm_net_init+0x79f/0x9e0 net/xfrm/xfrm_policy.c:3091
+ ops_init+0x10a/0x530 net/core/net_namespace.c:115
+ setup_net+0x2ed/0x690 net/core/net_namespace.c:291
+ copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396
+ create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106
+ unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
+ SYSC_unshare kernel/fork.c:2281 [inline]
+
+Problem is that when we get error during xfrm_net_init we will call
+xfrm_policy_fini which will acquire xfrm_policy_lock before it was
+initialized.  Just move it around so locks get set up first.
+
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Fixes: 283bc9f35bbbcb0e9 ("xfrm: Namespacify xfrm state/policy locks")
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/xfrm/xfrm_policy.c |   10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/net/xfrm/xfrm_policy.c
++++ b/net/xfrm/xfrm_policy.c
+@@ -3030,6 +3030,11 @@ static int __net_init xfrm_net_init(stru
+ {
+       int rv;
++      /* Initialize the per-net locks here */
++      spin_lock_init(&net->xfrm.xfrm_state_lock);
++      rwlock_init(&net->xfrm.xfrm_policy_lock);
++      mutex_init(&net->xfrm.xfrm_cfg_mutex);
++
+       rv = xfrm_statistics_init(net);
+       if (rv < 0)
+               goto out_statistics;
+@@ -3046,11 +3051,6 @@ static int __net_init xfrm_net_init(stru
+       if (rv < 0)
+               goto out;
+-      /* Initialize the per-net locks here */
+-      spin_lock_init(&net->xfrm.xfrm_state_lock);
+-      rwlock_init(&net->xfrm.xfrm_policy_lock);
+-      mutex_init(&net->xfrm.xfrm_cfg_mutex);
+-
+       return 0;
+ out:
diff --git a/queue-4.4/xfrm_user-validate-xfrm_msg_newae-incoming-esn-size-harder.patch b/queue-4.4/xfrm_user-validate-xfrm_msg_newae-incoming-esn-size-harder.patch
new file mode 100644 (file)
index 0000000..0eb0797
--- /dev/null
@@ -0,0 +1,39 @@
+From f843ee6dd019bcece3e74e76ad9df0155655d0df Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Thu, 23 Mar 2017 07:45:44 +0000
+Subject: xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
+
+From: Andy Whitcroft <apw@canonical.com>
+
+commit f843ee6dd019bcece3e74e76ad9df0155655d0df upstream.
+
+Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
+wrapping issues.  To ensure we are correctly ensuring that the two ESN
+structures are the same size compare both the overall size as reported
+by xfrm_replay_state_esn_len() and the internal length are the same.
+
+CVE-2017-7184
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/xfrm/xfrm_user.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -412,7 +412,11 @@ static inline int xfrm_replay_verify_len
+       up = nla_data(rp);
+       ulen = xfrm_replay_state_esn_len(up);
+-      if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
++      /* Check the overall length and the internal bitmap length to avoid
++       * potential overflow. */
++      if (nla_len(rp) < ulen ||
++          xfrm_replay_state_esn_len(replay_esn) != ulen ||
++          replay_esn->bmp_len != up->bmp_len)
+               return -EINVAL;
+       if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
diff --git a/queue-4.4/xfrm_user-validate-xfrm_msg_newae-xfrma_replay_esn_val-replay_window.patch b/queue-4.4/xfrm_user-validate-xfrm_msg_newae-xfrma_replay_esn_val-replay_window.patch
new file mode 100644 (file)
index 0000000..51adb35
--- /dev/null
@@ -0,0 +1,49 @@
+From 677e806da4d916052585301785d847c3b3e6186a Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Wed, 22 Mar 2017 07:29:31 +0000
+Subject: xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
+
+From: Andy Whitcroft <apw@canonical.com>
+
+commit 677e806da4d916052585301785d847c3b3e6186a upstream.
+
+When a new xfrm state is created during an XFRM_MSG_NEWSA call we
+validate the user supplied replay_esn to ensure that the size is valid
+and to ensure that the replay_window size is within the allocated
+buffer.  However later it is possible to update this replay_esn via a
+XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
+buffer matches the existing state and if so inject the contents.  We do
+not at this point check that the replay_window is within the allocated
+memory.  This leads to out-of-bounds reads and writes triggered by
+netlink packets.  This leads to memory corruption and the potential for
+priviledge escalation.
+
+We already attempt to validate the incoming replay information in
+xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
+is not trying to change the size of the replay state buffer which
+includes the replay_esn.  It however does not check the replay_window
+remains within that buffer.  Add validation of the contained
+replay_window.
+
+CVE-2017-7184
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/xfrm/xfrm_user.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -415,6 +415,9 @@ static inline int xfrm_replay_verify_len
+       if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
+               return -EINVAL;
++      if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
++              return -EINVAL;
++
+       return 0;
+ }