MIME-Version: 1.0
In-Reply-To: <20171201072743.47ztbmrql7ub327u@gauss3.secunet.de>
References: <089e082d0cb803507c055e6d5318@google.com> <001a11445ed4514b28055e947b48@google.com>
 <20171201072743.47ztbmrql7ub327u@gauss3.secunet.de>
From: Dmitry Vyukov <dvyukov@google.com>
Date: Fri, 1 Dec 2017 09:15:09 +0100
Message-ID: <CACT4Y+bh3P-c5ojJs2s9jqMO_xAmex+dTV5mUJLpFqFwwtxFuw@mail.gmail.com>
Subject: Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: syzbot 
        <bot+68bf59b49142965d6454163d7341e617a90139dc@syzkaller.appspotmail.com>,
        David Miller <davem@davemloft.net>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        LKML <linux-kernel@vger.kernel.org>, netdev <netdev@vger.kernel.org>,
        syzkaller-bugs@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3904
Lines: 99

On Fri, Dec 1, 2017 at 8:27 AM, Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> 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.


Please also follow this part:

> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> Note: all commands must start from beginning of the line in the email body.

This will greatly help keep the process running.

Thanks


> 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 <syzkaller@googlegroups.com>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
>  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
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20171201072743.47ztbmrql7ub327u%40gauss3.secunet.de.
> For more options, visit https://groups.google.com/d/optout.