Comment 0 for bug 1796748
Revision history for this message
| Mauricio Faria de Oliveira (mfo) wrote regression in 'ip --family bridge neigh' since linux v4.12+ | #0 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
[Impact]
* Netlink RTM_GETNEIGH requests for PF_BRIDGE are broken since linux v4.12.
* Users, tools (e.g., iproute2), and libraries (e.g., go netlink) that use
such request/family currently receive nothing back in the kernel response.
* The upstream fix resolves the breakage in the userspace-kernel interface
by explicitly checking for the old/broken request to ensure it's replied.
[Test Case]
* The command 'ip --family bridge neigh' returns nothing on broken kernels,
and matches 'bridge fdb show' on fixed kernels.
* Before:
$ ip --family bridge neigh
$
* After:
$ ip --family bridge neigh
dev ens3 lladdr 33:33:00:00:00:01 PERMANENT
dev ens3 lladdr 01:00:5e:00:00:01 PERMANENT
dev ens3 lladdr 33:33:ff:e9:9d:60 PERMANENT
* Reference:
$ bridge fdb show
33:
01:
33:
[Regression Potential]
* Low, for three reasons:
* The fix is contained in the RTM_GETNEIGH request for PF_BRIDGE family,
which is apparently not very used (this regression has existed between
v4.12 and v4.19).
* The checks introduced by the fix are conservative, based on the size
of the old request (the size of the old/new requests are different),
and it does nothing different in case the (old) size doesn't match.
* Given the above, only applications with message length and contents
specially hand-crafted (and likely not valid nor useful) might fail.
To the best of my knowledge, this is not the common case out there.
[Other Info]
* The patch is only applicable to v4.12+ (so not Trusty nor Xenial).
* The patch is the same for Bionic, Cosmic, and unstable.
* Upstream commit: bd961c9bc664 ("rtnetlink: fix rtnl_fdb_dump() for ndmsg header")
https:/
* I'll submit the patch shortly to the kernel-team mailing list.