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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ