Signed-off-by: Fabian Grünbichler <[email protected]>
---
Makefile | 2 +
...alidate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch | 51 ++++++++++++++++++++++
...alidate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch | 41 +++++++++++++++++
3 files changed, 94 insertions(+)
create mode 100644
CVE-2017-7184-0001-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch
create mode 100644
CVE-2017-7184-0002-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch
diff --git a/Makefile b/Makefile
index 0c12009..5de9672 100644
--- a/Makefile
+++ b/Makefile
@@ -265,6 +265,8 @@ ${KERNEL_SRC}/README ${KERNEL_CFG_ORG}: ${KERNELSRCTAR}
cd ${KERNEL_SRC}; patch -p1 <
../cgroup-cpuset-add-cpuset.remap_cpus.patch
cd ${KERNEL_SRC}; patch -p1 <
../CVE-2017-2596-kvm-page-reference-leakage-in-handle_vmon.patch
cd ${KERNEL_SRC}; patch -p1 <
../Revert-intel_idle-Add-CPU-model-54-Atom-N2000-series.patch
+ cd ${KERNEL_SRC}; patch -p1 <
../CVE-2017-7184-0001-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch
+ cd ${KERNEL_SRC}; patch -p1 <
../CVE-2017-7184-0002-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch
sed -i ${KERNEL_SRC}/Makefile -e
's/^EXTRAVERSION.*$$/EXTRAVERSION=${EXTRAVERSION}/'
touch $@
diff --git
a/CVE-2017-7184-0001-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch
b/CVE-2017-7184-0001-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch
new file mode 100644
index 0000000..369ee7e
--- /dev/null
+++
b/CVE-2017-7184-0001-xfrm_user-validate-XFRM_MSG_NEWAE-XFRMA_REPLAY_ESN_V.patch
@@ -0,0 +1,51 @@
+From 7f223b44260db3bd37b279534d287b76f2589fec Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <[email protected]>
+Date: Wed, 22 Mar 2017 07:29:31 +0000
+Subject: [PATCH 1/2] xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL
+ replay_window
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+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 <[email protected]>
+Acked-by: Steffen Klassert <[email protected]>
+Signed-off-by: Linus Torvalds <[email protected]>
+
+Signed-off-by: Fabian Grünbichler <[email protected]>
+---
+ net/xfrm/xfrm_user.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
+index 805681a..0e1f833 100644
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -415,6 +415,9 @@ static inline int xfrm_replay_verify_len(struct
xfrm_replay_state_esn *replay_es
+ 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;
+ }
+
diff --git
a/CVE-2017-7184-0002-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch
b/CVE-2017-7184-0002-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch
new file mode 100644
index 0000000..db77d70
--- /dev/null
+++
b/CVE-2017-7184-0002-xfrm_user-validate-XFRM_MSG_NEWAE-incoming-ESN-size-.patch
@@ -0,0 +1,41 @@
+From 4e5d70856a6d11cb6c174c6a304a7ef3788e00be Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <[email protected]>
+Date: Thu, 23 Mar 2017 07:45:44 +0000
+Subject: [PATCH 2/2] xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size
+ harder
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+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 <[email protected]>
+Acked-by: Steffen Klassert <[email protected]>
+Signed-off-by: Linus Torvalds <[email protected]>
+
+Signed-off-by: Fabian Grünbichler <[email protected]>
+---
+ net/xfrm/xfrm_user.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
+index 0e1f833..7a5a64e 100644
+--- a/net/xfrm/xfrm_user.c
++++ b/net/xfrm/xfrm_user.c
+@@ -412,7 +412,11 @@ static inline int xfrm_replay_verify_len(struct
xfrm_replay_state_esn *replay_es
+ 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)
--
2.1.4
_______________________________________________
pve-devel mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
