netdev - Re: [PATCH] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)

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: <CAHo-OoyQzJptNDcLe93o3-G10oRN+93ZZ35jKkLudSanvgn-2Q@mail.gmail.com>
Date:   Tue, 3 Sep 2019 14:17:17 +0200
From:   Maciej Żenczykowski <zenczykowski@...il.com>
To:     Lorenzo Colitti <lorenzo@...gle.com>
Cc:     David Ahern <dsahern@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128
 local route (and others)

Well, if you look at the commit my commit is fixing, ie.
  commit c7a1ce397adacaf5d4bb2eab0a738b5f80dc3e43
then you'll see this in the commit description:
  "- dst_nocount is handled by the RTF_ADDRCONF flag"
and the patch diff itself is from
  "f6i->fib6_flags = RTF_UP | RTF_NONEXTHOP;
   f6i->dst_nocount = true;"
to
  " .fc_flags = RTF_UP | RTF_ADDRCONF | RTF_NONEXTHOP,"

(and RTF_ANYCAST or RTF_LOCAL is later or'ed in in both versions of the code)

so I'm pretty sure that patch adds ADDRCONF unconditionally to that
function, and my commit unconditionally removes it.

Perhaps since then the call graph has changed???

Unfortunately I'm already in Europe on ancient ipv6 free networks and
since the office move my ipv6 lab is still not up (something about the
newly wired office jacks being blue which means corp, instead of any
other colour for a lab...) so I don't actually have an easy way to
test ipv6 slaac behaviour. :-(

On Tue, Sep 3, 2019 at 6:58 AM Lorenzo Colitti <lorenzo@...gle.com> wrote:
>
> On Tue, Sep 3, 2019 at 11:18 AM David Ahern <dsahern@...il.com> wrote:
> > addrconf_f6i_alloc is used for addresses added by userspace
> > (ipv6_add_addr) and anycast. ie., from what I can see it is not used for RAs
>
> Isn't ipv6_add_addr called by addrconf_prefix_rcv_add_addr, which is
> called by addrconf_prefix_rcv, which is called by
> ndisc_router_discovery? That is what happens when we process an RA;
> AFAICS manual configuration is inet6_addr_add, not ipv6_add_addr.
>
> Maciej, with this patch, do SLAAC addresses still have RTF_ADDRCONF?
> Per my previous message, my assumption would be no, but I might be
> misreading the code.