Activity log for bug #1796748

Date Who What changed Old value New value Message
2018-10-08 19:04:29 Mauricio Faria de Oliveira bug added bug
2018-10-08 19:14:56 Mauricio Faria de Oliveira summary regression in 'ip --family bridge neigh' since linux v4.12+ regression in 'ip --family bridge neigh' since linux v4.12
2018-10-08 19:27:37 Mauricio Faria de Oliveira description [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:33:00:00:00:01 dev ens3 self permanent 01:00:5e:00:00:01 dev ens3 self permanent 33:33:ff:e9:9d:60 dev ens3 self permanent [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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd961c9bc66497f0c63f4ba1d02900bb85078366 * I'll submit the patch shortly to the kernel-team mailing list. [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:33:00:00:00:01 dev ens3 self permanent     01:00:5e:00:00:01 dev ens3 self permanent     33:33:ff:e9:9d:60 dev ens3 self permanent [Regression Potential]  * Low, for three reasons:  * The fix is fairly contained (RTM_GETNEIGH request for PF_BRIDGE family).  * 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd961c9bc66497f0c63f4ba1d02900bb85078366  * I'll submit the patch shortly to the kernel-team mailing list.
2018-10-08 19:30:04 Ubuntu Kernel Bot linux (Ubuntu): status New Incomplete
2018-10-08 19:35:49 Mauricio Faria de Oliveira linux (Ubuntu): status Incomplete Confirmed
2018-10-09 06:48:17 Stefan Bader nominated for series Ubuntu Bionic
2018-10-09 06:48:17 Stefan Bader bug task added linux (Ubuntu Bionic)
2018-10-09 17:25:07 Joseph Salisbury linux (Ubuntu Bionic): status New Triaged
2018-10-09 17:25:09 Joseph Salisbury linux (Ubuntu): status Confirmed Triaged
2018-10-09 17:25:12 Joseph Salisbury linux (Ubuntu): importance Undecided Medium
2018-10-09 17:25:15 Joseph Salisbury linux (Ubuntu Bionic): importance Undecided Medium
2018-10-23 14:47:33 Kleber Sacilotto de Souza linux (Ubuntu Bionic): status Triaged Fix Committed
2018-10-24 13:35:14 Brad Figg tags verification-needed-bionic
2018-10-24 14:50:14 Brad Figg tags verification-needed-bionic verification-needed-bionic verification-needed-cosmic
2018-10-24 22:11:43 Mauricio Faria de Oliveira tags verification-needed-bionic verification-needed-cosmic verification-done-bionic verification-done-cosmic
2018-11-07 10:15:02 Stefan Bader nominated for series Ubuntu Cosmic
2018-11-07 10:15:02 Stefan Bader bug task added linux (Ubuntu Cosmic)
2018-11-07 10:15:15 Stefan Bader linux (Ubuntu Cosmic): importance Undecided Medium
2018-11-07 10:15:15 Stefan Bader linux (Ubuntu Cosmic): status New Fix Committed
2018-11-13 18:51:26 Launchpad Janitor linux (Ubuntu Bionic): status Fix Committed Fix Released
2018-11-13 18:51:26 Launchpad Janitor cve linked 2017-13168
2018-11-13 18:51:26 Launchpad Janitor cve linked 2018-15471
2018-11-13 18:51:26 Launchpad Janitor cve linked 2018-16658
2018-11-13 18:51:26 Launchpad Janitor cve linked 2018-9363
2018-11-13 19:09:36 Launchpad Janitor linux (Ubuntu Cosmic): status Fix Committed Fix Released
2018-11-17 03:22:23 Launchpad Janitor linux (Ubuntu): status Triaged Fix Released