Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751787AbdLAH1r (ORCPT ); Fri, 1 Dec 2017 02:27:47 -0500 Received: from a.mx.secunet.com ([62.96.220.36]:43326 "EHLO a.mx.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbdLAH1p (ORCPT ); Fri, 1 Dec 2017 02:27:45 -0500 Date: Fri, 1 Dec 2017 08:27:43 +0100 From: Steffen Klassert To: syzbot CC: , , , , Subject: Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3) Message-ID: <20171201072743.47ztbmrql7ub327u@gauss3.secunet.de> References: <089e082d0cb803507c055e6d5318@google.com> <001a11445ed4514b28055e947b48@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <001a11445ed4514b28055e947b48@google.com> User-Agent: NeoMutt/20170609 (1.8.3) X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: AFA35789-F974-461C-B350-D34E60756441 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2767 Lines: 79 On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote: > syzkaller has found reproducer for the following crash on > 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers > > > BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230 > net/xfrm/xfrm_state.c:1051 > Read of size 4 at addr ffff8801ccaa7af8 by task syzkaller231684/3045 The patch below should fix this. I plan to apply it to the ipsec tree after some advanced testing. Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies. 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. Reported-by: syzbot Signed-off-by: Steffen Klassert --- net/xfrm/xfrm_user.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 983b0233767b..57ad016ae675 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -1419,11 +1419,14 @@ static void copy_templates(struct xfrm_policy *xp, struct xfrm_user_tmpl *ut, 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 @@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family) 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; -- 2.14.1