VHOST-NET GUEST TO HOST ESCAPE - Kernel vulnerability - CVE-2019-14835

Public Date: September 18, 2019, 14:38
Updated September 3, 2021, 12:08 - Chinese, Simplified French Japanese Korean
Resolved Status
Important Impact

Insights vulnerability analysis

View exposed systems

Executive Summary 

A buffer overflow vulnerability was found in the Linux kernel's networking virtualization functionality that could be abused during live migration(s) of virtual machine guests. A privileged guest user may pass descriptors with invalid length to the host when live migration is underway and escalate their privileges on the host.

Technical Details and Background 

The issue has been assigned CVE-2019-14835 with a severity impact of Important.

This flaw can only be exploited during guest live migration(s). Patches and alternate mitigations are detailed below.

CVE-2019-14835 - kernel: vhost-net: guest to host kernel escape during migration

A buffer overflow vulnerability was found in the Linux kernel's networking virtualization functionality that could be abused during live migrations of virtual machine guests. A privileged guest user may pass descriptors with invalid length to the host, while live migration is underway, and escalate their privileges on the host. This is unlikely to affect single-host systems where guest live migration is not configured.


Red Hat would like to thank Peter Pi from Tencent Blade Team.

Additional References 





Impacted Products

Red Hat Product Security has rated this update as having a security impact of Important.

The following Red Hat product versions are impacted:

  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Virtualization 
  • Red Hat OpenStack Platform (images shipping kernel) 
  • Container-Native Virtualization (CNV)

While Red Hat's Linux Containers are not directly impacted by virtualization flaws, their security relies upon the integrity of the host kernel’s environment. Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers. To protect the privacy of the containers in use, you will need to ensure that the Container host (such as Red Hat Enterprise Linux, Red Hat CoreOS or Atomic Host) has been updated against these attacks. Red Hat has released an updated Atomic Host for this use case.

Diagnose your vulnerability

Use the detection script to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well.

Determine if your system is vulnerable

Current Version: 1.1

Take Action

Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as erratas are available. Customers are urged to apply the appropriate updates immediately.


At this time there is no reliable method to detect if the exploit has successfully been run on a system due to the low-level method of exploitation.

Red Hat Product Security strongly recommends customers review the threat profile of their systems, especially multi-tenant workloads. Consider patching higher priority systems that require guest migration abilities.

A kpatch for customers running supported versions of Red Hat Enterprise Linux 7 or greater will be available. Please open a support case to gain access to the kpatch.

For more details about what a kpatch is: Is live kernel patching (kpatch) supported in RHEL 7 and beyond?

Updates for Affected Products

Red Hat Enterprise Linux 8 (z-stream)kernelRHSA-2019:2827
Red Hat Enterprise Linux 8kernel-rtRHSA-2019:2828
Red Hat Enterprise Linux 7 (z-stream)kernelRHSA-2019:2829
Red Hat Enterprise Linux 7kernel-rtRHSA-2019:2830
Red Hat Enterprise Linux 7kpatch-patchRHSA-2019:2854
Red Hat Enterprise Linux 6 (z-stream)kernelRHSA-2019:2863
Red Hat Virtualization 4.3redhat-virtualization-hostRHSA-2019:2889
Red Hat Virtualization 4.2 EUSredhat-virtualization-hostRHSA-2019:2924


Option #1 Disabling vhost-net

Vhost-net functionality can be disabled on a per-guest basis. See DISABLING VHOST-NET.

Alternatively, the kernel module named 'vhost_net' which contains the affected code can be blacklisted using the standard blacklisting techniques. See How do I blacklist a kernel module to prevent it from loading automatically? for instructions on how to complete the task. 

Guests utilizing vhost-net functionality need to be rebooted for the changes to take effect.

Option #2 Disabling guest live migration

The issue is only exploitable from the guest when live migration is underway. Avoiding migration by either disabling automatic migration completely or not migrating the guests to another host manually, is an effective way to avoid exploitation.

CNV - Disable Live migration Support

Disable the live migration feature by removing the "LiveMigration" field from data: feature-gates: in the kubevirt-config configuration file, which is located in the kubevirt namespace

Edit the kubevirt-config configuration file and remove the LiveMigration from the `feature-gates` line:

$ oc edit configmap kubevirt-config -n kubevirt
  feature-gates: "LiveMigration"
Remove the “LiveMigration” term in the line above.

The virt-api and virt-controller pods need to be restarted to apply the changes.

$ oc delete pod virt-api -n kube-system
$ oc delete pod virt-controller -n kube-system

Red Hat Virtualization - disabling automatic migration

Migrations can be disabled at either the cluster level or for individual guests.  Typically, Red Hat Virtualization will automatically migrate guests to other hosts within a cluster according to load measurements, compatibility, and resilience and availability policy.  Guests may also be migrated during maintenance as hosts within a cluster are put into maintenance mode.

Automatic migration policy can be controlled on a cluster level, or in individual host configuration.

To ensure guests are not migrated when a host is put into maintenance mode, either make sure that the guests are configured with Do not allow migration, or shut down all the guests on that host before putting it into maintenance mode.

Customers are advised to take a risk-based approach to mitigating this issue. Systems that require high degrees of security and trust should be addressed first and isolated from untrusted systems until treatments can be applied to those systems to reduce the risk of exploit.

Performance Impact

Updating the kernel to a release that contains the fix will have no noticeable performance impact.

A performance impact is expected if using the mitigation of disabling vhost-net. The exact measures will be dependant on the networking load on the system.

Ansible Playbook

Additionally, a mitigation playbook is available which will prevent the vulnerable kernel module from being loaded. This playbook will reboot your systems to ensure the module is unloaded. To use it, specify the inventory names of the target systems in the HOSTS variable. For example:

ansible-playbook -e HOSTS=myhost1,myhost2 CVE-2019-14835_blacklist_mitigate.yml

A detached GPG signature is also available.

Mitigate with Ansible

Current version: 1.0