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: <66145819-f0aa-794f-4045-1c203b260f47@gmail.com>
Date:   Mon, 9 Nov 2020 10:05:15 +0100
From:   Oliver Herms <oliver.peter.herms@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...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 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.

Kind Regards
Oliver