Neighbour confirmation broken, breaks ARP cache aging
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Daniel Axtens | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[SRU Justification]
[Impact]
A host can lose access to another host whose MAC address changes if they have active connections to other hosts that share a route. The ARP cache does not time out as expected - instead the old MAC address is continuously reconfirmed.
[Fix]
Apply series [1], which changes the algorithm for neighbour confirmation.
That is, from upstream:
51ce8bd4d17a net: pending_confirm is not used anymore
0dec879f636f net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP
63fca65d0863 net: add confirm_neigh method to dst_ops
c3a2e8370534 tcp: replace dst_confirm with sk_dst_confirm
c86a773c7802 sctp: add dst_pending_confirm flag
4ff0620354f2 net: add dst_pending_confirm flag to skbuff
9b8805a32559 sock: add sk_dst_
[Test case]
Create 3 real or virtual systems, all hooked up to a switch.
One system needs an active-backup bond with fail_over_mac=1 num_grat_arp=0.
Put all the systems in the same subnet, e.g. 192.168.200.0/24
Call the system with the bond A, and the other two systems B and C.
On B, run in 3 shells:
- netperf -t TCP_RR to C
- ping -f A
- watch 'ip -s neigh show 192.168.200.0/24'
On A, cause the bond to fail over.
Observe that:
- without the patches, B intermittently fails to notice the change in A's MAC address. This presents as the ping failing and not recovering, and the arp table showing the old mac address never timing out and never being replace with a new mac address.
- with the patches, the arp cache times out and B sends another mac probe and detects A's new address.
It helps to use taskset to put ping and netperf on the same CPU, or use single-CPU vms.
See [2] for more details.
[References]
[2] Original report: https://<email address hidden>
[1]: https:/
CVE References
Changed in linux (Ubuntu Zesty): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification- needed- xenial' to 'verification- done-xenial' . If the problem still exists, change the tag 'verification- needed- xenial' to 'verification- failed- xenial' .
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.
See https:/ /wiki.ubuntu. com/Testing/ EnableProposed for documentation how to enable and use -proposed. Thank you!