Skip to contentSkip to conversation

Patch "xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies." has been added to the 4.14-stable tree

PATCH [email protected] 1 participant 1 message Feb 23, 2018

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.

to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
xfrm-fix-stack-out-of-bounds-with-misconfigured-transport-mode-policies.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Fri Feb 23 11:45:09 CET 2018

From: Steffen Klassert <[email protected]>
Date: Fri, 8 Dec 2017 08:07:25 +0100
Subject: xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.

From: Steffen Klassert <[email protected]>

[ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ]

On policies with a transport mode template, we pass the addresses from the flowi to xfrm_state_find(), assuming that the IP addresses (and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough. It is possible to configure policies with transport mode template where the address family of the template does not match the selectors address family. This lead to stack-out-of-bound reads because we compare arddesses of the wrong family. Fix this by refusing such a configuration, address family can not change on transport mode.

We use the assumption that, on transport mode, the first templates address family must match the address family of the policy selector. Subsequent transport mode templates must mach the address family of the previous template.

---
 net/xfrm/xfrm_user.c |    9 +++++++++
 1 file changed, 9 insertions(+)
net/xfrm/xfrm_user.c +9 -0
@@ -1417,11 +1417,14 @@ static void copy_templates(struct xfrm_p
 
 static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
 {
+	u16 prev_family;
 	int i;
 
 	if (nr > XFRM_MAX_DEPTH)
 		return -EINVAL;
 
+	prev_family = family;
+
 	for (i = 0; i < nr; i++) {
 		/* We never validated the ut->family value, so many
 		 * applications simply leave it at zero.  The check was
@@ -1433,6 +1436,12 @@ static int validate_tmpl(int nr, struct
 		if (!ut[i].family)
 			ut[i].family = family;
 
+		if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+		    (ut[i].family != prev_family))
+			return -EINVAL;
+
+		prev_family = ut[i].family;
+
 		switch (ut[i].family) {
 		case AF_INET:
 			break;

Patches currently in stable-queue which might be from [email protected] are

queue-4.14/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch queue-4.14/xfrm-fix-stack-out-of-bounds-with-misconfigured-transport-mode-policies.patch queue-4.14/xfrm-fix-xfrm_input-to-verify-state-is-valid-when-encap_type-0.patch queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch queue-4.14/esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.patch queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch