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] [day] [month] [year] [list]
Date:   Mon, 9 Nov 2020 15:59:58 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Stefano Brivio <sbrivio@...hat.com>
Cc:     Jianlin Shi <jishi@...hat.com>, David Ahern <dsahern@...il.com>,
        Florian Westphal <fw@...len.de>,
        Aaron Conole <aconole@...hat.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net] tunnels: Fix off-by-one in lower MTU bounds for
 ICMP/ICMPv6 replies

On Fri,  6 Nov 2020 17:59:52 +0100 Stefano Brivio wrote:
> Jianlin reports that a bridged IPv6 VXLAN endpoint, carrying IPv6
> packets over a link with a PMTU estimation of exactly 1350 bytes,
> won't trigger ICMPv6 Packet Too Big replies when the encapsulated
> datagrams exceed said PMTU value. VXLAN over IPv6 adds 70 bytes of
> overhead, so an ICMPv6 reply indicating 1280 bytes as inner MTU
> would be legitimate and expected.
> 
> This comes from an off-by-one error I introduced in checks added
> as part of commit 4cb47a8644cc ("tunnels: PMTU discovery support
> for directly bridged IP packets"), whose purpose was to prevent
> sending ICMPv6 Packet Too Big messages with an MTU lower than the
> smallest permissible IPv6 link MTU, i.e. 1280 bytes.
> 
> In iptunnel_pmtud_check_icmpv6(), avoid triggering a reply only if
> the advertised MTU would be less than, and not equal to, 1280 bytes.
> 
> Also fix the analogous comparison for IPv4, that is, skip the ICMP
> reply only if the resulting MTU is strictly less than 576 bytes.
> 
> This becomes apparent while running the net/pmtu.sh bridged VXLAN
> or GENEVE selftests with adjusted lower-link MTU values. Using
> e.g. GENEVE, setting ll_mtu to the values reported below, in the
> test_pmtu_ipvX_over_bridged_vxlanY_or_geneveY_exception() test
> function, we can see failures on the following tests:
> 
>              test                | ll_mtu
>   -------------------------------|--------
>   pmtu_ipv4_br_geneve4_exception |   626
>   pmtu_ipv6_br_geneve4_exception |  1330
>   pmtu_ipv6_br_geneve6_exception |  1350
> 
> owing to the different tunneling overheads implied by the
> corresponding configurations.
> 
> Reported-by: Jianlin Shi <jishi@...hat.com>
> Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
> Signed-off-by: Stefano Brivio <sbrivio@...hat.com>

Applied, thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ