[Bug 1844455] Update Released

[Łukasz Zemczak]

The verification of the Stable Release Update for libvirt has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1844455

Title:
  Memory leak of struct _virPCIDeviceAddress on libvirt

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  Fix Committed
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Fix Committed
Status in libvirt source package in Bionic:
  Fix Released
Status in libvirt source package in Eoan:
  Fix Released
Status in libvirt source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * There's a long-term memory leak in libvirt related to the PCI information gathering from sysfs in Linux, specially related with SR-IOV devices. This was fixed by commit 38816336 ("node_device_conf: Don't leak @physical_function in virNodeDeviceGetPCISRIOVCaps") [ libvirt.org/git/?p=libvirt.git;a=commit;h=38816336 ].

  * In comment #9 there is a detailed explanation of what's going on,
  but the summary is that the variable physical_function (member of a
  PCI structure), of type _virPCIDeviceAddress, is allocated on
  virPCIGetDeviceAddressFromSysfsLink() and should be freed before reuse
  in virNodeDeviceGetPCISRIOVCaps(), but it wasn't before the fix was
  introduced.

  * The impact of the issue is a memory leak usually small but that may
  grow bigger depending on the amount of PCI devices and how/when they
  are enumerated by libvirt; if some user of those functions are
  actively exercising the leak path it may become a problem (OOM
  situation).

  [Test Case]
  * The basic testing done to exercise the memory leak path was running the virsh tool to generate the XML output of a SR-IOV PCI device in a loop, like:

  while true; do virsh nodedev-dumpxml pci_0000_08_12_0 >/dev/null; done

  * This was executed while Valgrind was used to debug libvirtd, in
  order to collect the signature of the leak. Without the patch we get
  the "definitely lost" type of leak with the PCI backtrace (on comment
  #9), whereas with the patch we don't see the leak anymore.

  [Regression Potential]
  * The potential of regressions is really low - the fix is upstream for a while and in Focal package, and it is self-contained and not intrusive. Considering hypothetical scenarios, if there's an issue with the fix it should come in form of unused memory or double-free (which is usually harmless), and only in PCI enumeration (or PCI XML generation) paths.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1844455/+subscriptions