This bug was fixed in the package linux - 4.18.0-11.12

---------------
linux (4.18.0-11.12) cosmic; urgency=medium

  * linux: 4.18.0-11.12 -proposed tracker (LP: #1799445)

  * arm64: snapdragon: WARNING: CPU: 0 PID: 1 arch/arm64/kernel/setup.c:271
    reserve_memblock_reserved_regions (LP: #1797139)
    - SAUCE: arm64: Fix /proc/iomem for reserved but not memory regions

  * arm64: snapdragon: WARNING: CPU: 0 PID: 1 at drivers/irqchip/irq-gic.c:1016
    gic_irq_domain_translate (LP: #1797143)
    - SAUCE: arm64: dts: msm8916: camms: fix gic_irq_domain_translate warnings

  * The front MIC can't work on the Lenovo M715 (LP: #1797292)
    - ALSA: hda/realtek - Fix the problem of the front MIC on the Lenovo M715

  * Provide mode where all vCPUs on a core must be the same VM (LP: #1792957)
    - KVM: PPC: Book3S HV: Provide mode where all vCPUs on a core must be the 
same
      VM

  * fscache: bad refcounting in fscache_op_complete leads to OOPS (LP: #1797314)
    - SAUCE: fscache: Fix race in decrementing refcount of op->npages

  * hns3: autoneg settings get lost on down/up (LP: #1797654)
    - net: hns3: Fix for information of phydev lost problem when down/up

  * not able to unwind the stack from within __kernel_clock_gettime in the Linux
    vDSO (LP: #1797963)
    - powerpc/vdso: Correct call frame information

  * Signal 7 error when running GPFS tracing in cluster (LP: #1792195)
    - powerpc/mm/books3s: Add new pte bit to mark pte temporarily invalid.
    - powerpc/mm/radix: Only need the Nest MMU workaround for R -> RW transition

  * Support Edge Gateway's WIFI LED (LP: #1798330)
    - SAUCE: mwifiex: Switch WiFi LED state according to the device status

  * Support Edge Gateway's Bluetooth LED (LP: #1798332)
    - SAUCE: Bluetooth: Support for LED on Edge Gateways

  * kvm doesn't work on 36 physical bits systems (LP: #1798427)
    - KVM: x86: fix L1TF's MMIO GFN calculation

  * CVE-2018-15471
    - xen-netback: fix input validation in xenvif_set_hash_mapping()

  * regression in 'ip --family bridge neigh' since linux v4.12 (LP: #1796748)
    - rtnetlink: fix rtnl_fdb_dump() for ndmsg header

 -- Stefan Bader <stefan.ba...@canonical.com>  Tue, 23 Oct 2018 18:59:15
+0200

** Changed in: linux (Ubuntu Cosmic)
       Status: Fix Committed => Fix Released

-- 
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:
  Triaged
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

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