linux-kernel - neighbour entry incorrectly moved to NUD

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Mon, 18 Feb 2019 15:43:14 +1300 (NZDT)
From:   ash.millar@...iedtelesis.co.nz
To:     netdev@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: neighbour entry incorrectly moved to NUD_REACHABLE

We have encountered an issue resulting from commit 2724680bceee ("neigh: Keep neighbour cache entries if number of them is small enough."), which allows stale entries to remain in the neigh table indefinitely if the total number of entries is less than gc_thresh1.

This issue arises if:
- a stale entry has existed for a long time, so it has a sufficiently old neigh->confirmed value
- the neighbour itself has sinced change MAC address
- we then try to ping the neighbour

When we ping the neighbour, the entry moves into NUD_DELAY as expected. But then, within neigh_timer_handler(), an incorrect jiffie comparison causes time_before_eq(now, neigh->confirmed + NEIGH_VAR(neigh->parms, DELAY_PROBE_TIME)) to return true and the entry is erroneously moved to NUD_REACHABLE. The entry becomes stuck in this state, even though it is not actually reachable as the neighbour has since changed MAC address.

The necessary age of neigh->confirmed for this to occur depends on the platform. It occurs after approximitely 100 days on a 32-bit platform with 250HZ.

We have resolved this by setting gc_thresh1 = 0, which effectively undoes commit 2724680bceee.

I would like to know if anyone else has observed this or has an alternative solution.

Kind regards,
Ash