netdev - Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 07 Feb 2018 20:46:26 +0100
From:   Yves-Alexis Perez <corsac@...ian.org>
To:     Mike Maloney <maloneykernel@...il.com>
Cc:     Mike Maloney <maloney@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, debian-kernel@...ts.debian.org,
        Tobias Brunner <tobias@...ongswan.org>
Subject: Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16

On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <corsac@...ian.org>
> 
> Hi Yves-Alexis -
> 
> I apologize for the problem.  It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> potentially problematic in other ways as well.

Maybe. I tried with removing the MTU setting, and I get (on ping again)

févr. 07 20:44:01 scapa kernel: mtu: 1266

which means I would get -EINVAL on standards kernels, which is not really good
either.

> But also it could seem unfortunate that the code with my fix does not
> look at actual packet size, but instead only looks at the MTU and then
> fails, even if no packet was going to be so large.  The intention of
> my patch was to prevent a negative number while calculating the
> maxfraglen in  __ip6_append_data().  An alternative fix maybe to
> instead return an error only if the mtu is less than or equal to the
> fragheaderlen.   Something like:
> 
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 3763dc01e374..5d912a289b95 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk,
> struct inet_cork_full *cork,
>                 if (np->frag_size)
>                         mtu = np->frag_size;
>         }
> -       if (mtu < IPV6_MIN_MTU)
> -               return -EINVAL;
>         cork->base.fragsize = mtu;
>         if (dst_allfrag(rt->dst.path))
>                 cork->base.flags |= IPCORK_ALLFRAG;
> @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk,
> 
>         fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len +
>                         (opt ? opt->opt_nflen : 0);
> +       if (mtu < fragheaderlen + 8)
> +               return -EINVAL;
>         maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
>                      sizeof(struct frag_hdr);
>                         (opt ? opt->opt_nflen : 0);
> 
> But then we also have to convince ourselves that maxfraglen can never
> be <= 0.  I'd have to think about that.
> 
> I am not sure if others have thoughts on supporting MTUs configured
> below the min in the spec.
> 
Here, the MTU is not below, so I'm not sure what happens.

Regards,
-- 
Yves-Alexis
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)