netdev - Re: PROBLEM: can't ping anycast IPv6 address on lo interface

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:   Tue, 07 Jul 2020 08:24:57 +0000
From:   thomas.gambier@...edi.com
To:     David Ahern <dsahern@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev@...r.kernel.org, Julien Muchembled <jm@...edi.com>,
        Jean-Paul Smets <jp@...edi.com>,
        Juliusz Chroboczek <jch@...f.fr>
Subject: Re: PROBLEM: can't ping anycast IPv6 address on lo interface

On 2020-07-07 02:25, David Ahern wrote:
> [ sorry for the delay; on PTO for a couple weeks ]
> 
> On 6/26/20 3:20 AM, thomas.gambier@...edi.com wrote:
>> Hello,
>> 
>> this is the first time I report a bug to the kernel team. Please let 
>> me
>> know if there are any missing information or if I should post on
>> bugzilla instead.
>> 
>> 
>> Since Linux 5.2, I can't ping anycast address on lo interface.
>> 
>> If you enable IPv6 forwarding for an interface and add a IPv6 address
>> range on this interface, it is possible to ping the addres 0 of the
>> range (anycast address). This doesn't work for "lo" interface since
>> Linux 5.2.
>> 
>> I bisected to find that the commit
>> c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
>> (https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43)
>> introduced the regression. Please note that the regression is still
>> present on master branch of net repository (commit
>> 2570284060b48f3f79d8f1a2698792f36c385e9a from yesterday).
>> 
>> I attach my config file to this email (this config was used to compile
>> latest master branch).
>> 
>> In order to reproduce you can use this small script:
>> 
>> root@...nel-compil-vm:~# cat test.bash
>> #! /bin/bash
>> echo 1 >  /proc/sys/net/ipv6/conf/all/forwarding
>> ip -6 a add fc12::1/16 dev lo
>> sleep 2
>> echo "pinging lo"
>> ping6 -c 2 fc12::
>> 
> 
> Thanks for the quick reproducer.
> 
>> 
>> Before the regression you will see:
>> pinging lo
>> PING fc12::(fc12::) 56 data bytes
>> 64 bytes from fc12::1: icmp_seq=1 ttl=64 time=0.111 ms
>> 64 bytes from fc12::1: icmp_seq=2 ttl=64 time=0.062 ms
>> 
>> 
>> After the regression you will see:
>> pinging lo
>> PING fc12::(fc12::) 56 data bytes
>> From fc12::: icmp_seq=1 Destination unreachable: No route
>> From fc12::: icmp_seq=2 Destination unreachable: No route
>> 
> 
> This solves the problem for me; can you try it out in your environment?
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index ea0be7cf3d93..f3279810d765 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -3405,7 +3405,7 @@ static bool fib6_is_reject(u32 flags, struct
> net_device *dev, int addr_type)
>         if ((flags & RTF_REJECT) ||
>             (dev && (dev->flags & IFF_LOOPBACK) &&
>              !(addr_type & IPV6_ADDR_LOOPBACK) &&
> -            !(flags & RTF_LOCAL)))
> +            !(flags & (RTF_ANYCAST | RTF_LOCAL))))
>                 return true;
> 
>         return false;

Yes, I confirm this patch solves the bug.

Thank you very much.