netdev - Re: [PATCH next] neigh: initialize neigh entry correctly during arp processing

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: <CAPA1RqDjJvZkCTt0w=4LPps1vCdKEEVemXWjBXRkZMQGaLPDnw@mail.gmail.com>
Date:   Thu, 17 Aug 2017 09:58:33 +0900
From:   吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
To:     Mahesh Bandewar <mahesh@...dewar.net>
Cc:     David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        netdev <netdev@...r.kernel.org>,
        Ido Schimmel <idosch@...lanox.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Reshetova Elena <elena.reshetova@...el.com>,
        Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        Florian Westphal <fw@...len.de>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Ihar Hrachyshka <ihrachys@...hat.com>,
        David Ahern <dsa@...ulusnetworks.com>,
        Zhang Shengju <zhangshengju@...s.chinamobile.com>,
        Mahesh Bandewar <maheshb@...gle.com>,
        吉藤英明 <hideaki.yoshifuji@...aclelinux.com>,
        YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH next] neigh: initialize neigh entry correctly during arp processing

Hi,

2017-08-17 9:02 GMT+09:00 Mahesh Bandewar <mahesh@...dewar.net>:
> From: Mahesh Bandewar <maheshb@...gle.com>
>
> If the ARP processing creates a neigh entry, it's immediately marked
> as STALE without timer and stays that way in that state as long as
> host do not send traffic to that neighbour.
>
> I observed this on hosts which are in IPv6 environment, where there is
> very little to no IPv4 traffic and neigh-entries are stuck in STALE
> mode. Ideally, the host should have PROBEd these neighbours before it
> can send the first packet out.

No, we do not probe neighbors until we have packet for/through
it.


>
> It happens as a result of following call sequence in an environment
> where host is mostly quiet as far as IPv4 traffic but few connected
> hosts/gateways are sending ARPs.
>
>    arp_process()
>      neigh_event_ns()
>        neigh_lookup()
>          neigh_create()
>            neigh_alloc()
>              nud_state=NUD_NONE
>      neigh_update(nud_state=NUD_STALE)
>
> In the above scenario, the neighbour entry does not get a chance to get
> PROBEd as subsequent call to neigh_update() marks  this entry STALE.
> This patch initializes the neigh-entry correctly if it was created as a
> result of neigh_lookup instead of just updating it in neigh_event_ns()
> right after creating it.
>
> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
> ---
>  net/core/neighbour.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 16a1a4c4eb57..d8a35db6c43b 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -1300,9 +1300,13 @@ struct neighbour *neigh_event_ns(struct neigh_table *tbl,
>  {
>         struct neighbour *neigh = __neigh_lookup(tbl, saddr, dev,
>                                                  lladdr || !dev->addr_len);
> -       if (neigh)
> -               neigh_update(neigh, lladdr, NUD_STALE,
> -                            NEIGH_UPDATE_F_OVERRIDE, 0);
> +       if (neigh) {
> +               if (neigh->nud_state & NUD_VALID)
> +                       neigh_update(neigh, lladdr, NUD_STALE,
> +                                    NEIGH_UPDATE_F_OVERRIDE, 0);
> +               else
> +                       neigh_event_send(neigh, NULL);
> +       }
>         return neigh;
>  }
>  EXPORT_SYMBOL(neigh_event_ns);
> --
> 2.14.1.480.gb18f417b89-goog
>