xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
authorAndy Whitcroft <apw@canonical.com>
Thu, 23 Mar 2017 07:45:44 +0000 (07:45 +0000)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 29 Mar 2017 15:40:15 +0000 (08:40 -0700)
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>
net/xfrm/xfrm_user.c

index cdf887f..40a8aa3 100644 (file)
@@ -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)