8.66. hypervkvpd

Bug Fixes

BZ#920032

Previously, the hypervkvpd service registered to two netlink multicast groups, one of which was used by the cgred service. When hypervkvpd received a netlink message, it was interpreted blindly as its own. As a consequence, hypervkvpd terminated unexpectedly with a segmentation fault. After this update, hypervkvpd now registers only to its own netlink multicast group and verifies the type of the incoming netlink message. Using hypervkvpd when the cgred service is running no longer leads to a segmentation fault.

BZ#962565

Prior to this update, the hypervkvpd init script did not check if Hyper-V driver modules were loaded into the kernel. If hypervkvpd was installed, it started automatically on system boot, even if the system was not running as a guest machine on a Hyper-V hypervisor. Verification has been added to the hypervkvpd init script to determine whether Hyper-V driver modules are loaded into the kernel. As a result, if the modules are not loaded into the kernel, hypervkvpd now does not start, but displays a message that proper driver modules are not loaded.

BZ#977861

Previously, hypervkvpd was not built with sufficiently secure compiler options, which could, consequently, make the compiled code vulnerable. The hypervkvpd daemon has been built with full read-only relocation (RELRO) and position-independent executable (PIE) flags. As a result, the compiled code is more secure and better guarded against possible buffer overflows.

BZ#983851

When using the Get-VMNetworkAdapter command to query a virtual machine network adapter, each subnet string has to be separated by a semicolon. Due to a bug in the IPv6 subnet enumeration code, the IPv6 addresses were not listed. A patch has been applied, and the IPv6 subnet enumeration now works as expected.