This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:

apport-collect 1796748

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

** Changed in: linux (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1796748

Title:
  regression in 'ip --family bridge neigh' since linux v4.12

Status in linux package in Ubuntu:
  Incomplete

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1796748/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to