netdev - Re: [PATCH] IPv6: Set SIT tunnel hard_header

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]

Message-ID: <CA+FuTSdSZxiikn2vN_YH=KpmJ2un0PjK7T9qUQwHi6OSfbTMmA@mail.gmail.com>
Date:   Mon, 9 Nov 2020 10:10:37 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Oliver Herms <oliver.peter.herms@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH] IPv6: Set SIT tunnel hard_header_len to zero

On Mon, Nov 9, 2020 at 4:05 AM Oliver Herms
<oliver.peter.herms@...il.com> wrote:
>
>
> On 04.11.20 20:52, Willem de Bruijn wrote:
> >>>> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> >>>
> >>> How did you arrive at this SHA1?
> >> I think the legacy usage of hard_header_len in ipv6/sit.c was overseen in c54419321455.
> >> Please correct me if I'm wrong.
> >
> > I don't see anything in that patch assign or modify hard_header_len.
> >
> It's not assigning or modifying it but changing expectations about how dev->hard_header_len is to be used.
>
> The patch changed the MTU calculation from:
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len - tunnel->hlen;
>
> to this:
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len - sizeof(struct iphdr);
>
> Later is became this (in patch 23a3647. This is the current implementation.):
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len - sizeof(struct iphdr) - tunnel_hlen;
>
> Apparently the initial usage of dev->hard_header_len was that it contains the length
> of all headers before the tunnel payload. c54419321455 changed it to assuming dev->hard_header_len
> does not contain the tunnels outter IP header. Thus I think the bug was introduced by c54419321455.

And the only header in the case of SIT is that outer ip header. Got it, thanks.

Overly conservative MTU calculation is one issue. Packet sockets also
expect read/write link layer access with SOCK_RAW, which does not work
correctly for sit. I'm not sure that it ever did.

The chosen commit predates all stable trees, which is the most important point.

Acked-by: Willem de Bruijn <willemb@...gle.com>

Could ip6 tunnels have the same issue? In ip6_tnl_dev_init_gen,

        dev->hard_header_len = LL_MAX_HEADER + t_hlen;