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] [day] [month] [year] [list]

Message-Id: <20170818.161011.1703904478516944881.davem@davemloft.net>
Date:   Fri, 18 Aug 2017 16:10:11 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     mahesh@...dewar.net
Cc:     edumazet@...gle.com, netdev@...r.kernel.org, idosch@...lanox.com,
        ishkamiel@...il.com, keescook@...omium.org,
        elena.reshetova@...el.com, sowmini.varadhan@...cle.com,
        fw@...len.de, roopa@...ulusnetworks.com, ihrachys@...hat.com,
        dsa@...ulusnetworks.com, zhangshengju@...s.chinamobile.com,
        maheshb@...gle.com
Subject: Re: [PATCH next] neigh: initialize neigh entry correctly during
 arp processing

From: Mahesh Bandewar <mahesh@...dewar.net>
Date: Wed, 16 Aug 2017 17:02:51 -0700

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

Please provide, in the commit message, a list of events including an
example packet exchange and timers firing which explains how this
situation arises.

Thank you.