Bug 1594977 (CVE-2018-14636) - CVE-2018-14636 openstack-neutron: eavesdropping private traffic due to trunk ports after live migration
Summary: CVE-2018-14636 openstack-neutron: eavesdropping private traffic due to trunk ...
Alias: CVE-2018-14636
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
: 1594825 (view as bug list)
Depends On: 1594978 1614596 1614597 1614598 1614599 1614600 1678057
Blocks: 1594979
TreeView+ depends on / blocked
Reported: 2018-06-25 21:57 UTC by Laura Pardo
Modified: 2021-08-04 15:02 UTC (History)
21 users (show)

Fixed In Version: openstack-neutron, openstack-neutron 12.0.3, openstack-neutron 11.0.5
Doc Type: If docs needed, set a value
Doc Text:
Live-migrated instances are briefly able to inspect traffic for other instances on the same hypervisor. This brief window could be extended indefinitely if the instance's port is set administratively down prior to live-migration and kept down after the migration is complete. This is possible due to the Open vSwitch integration bridge being connected to the instance during migration. When connected to the integration bridge, all traffic for instances using the same Open vSwitch instance would potentially be visible to the migrated guest, as the required Open vSwitch VLAN filters are only applied post-migration.
Clone Of:
Last Closed: 2021-07-06 16:40:20 UTC

Attachments (Terms of Use)

Description Laura Pardo 2018-06-25 21:57:09 UTC
A flaw was found in Openstack Neutron. During live-migration there is a small time window where the ports of instances are untagged. Instances have a port trunked to the integration bridge and receive 802.1Q tagged private traffic from other tenants. If the port is administratively down during live migration, the port will remain in trunk mode indefinitely. Traffic is possible between ports is that are administratively down, even between tenants self-service networks. This allows end users within their own private network to receive from, and send traffic to, other private networks on the same compute node.



Comment 1 Laura Pardo 2018-06-25 21:57:46 UTC
Created openstack-neutron tracking bugs for this issue:

Affects: openstack-rdo [bug 1594978]

Comment 2 Joshua Padman 2018-07-04 00:56:34 UTC
*** Bug 1594825 has been marked as a duplicate of this bug. ***

Comment 8 Miguel Angel Ajo 2018-08-10 14:58:49 UTC
Oh, the patches referenced on the bz are incorrect for this bz, also the 2nd launchpad ( https://bugs.launchpad.net/neutron/+bug/1767422 ).

Those patches, and that second launchpad address the case when an agent (dhcp/l3/etc) get's a port plugged, but then the openvswitch-agent is not able to tag the port, it remains untagged, and it's a trunk port.

But those patches *are not* addressing the instances themselves.

This needs to be addressed in nova, or os-vif by plugging the port in vlan 4095, then, when neutron is ready will re-plug to the right vlan.

Comment 9 Slawek Kaplonski 2018-08-21 10:19:41 UTC
I checked that and it is like Miguel wrote in last comment. This issue isn't fixed in any of OSP versions yet.
It should be fixed in os-vif module as this module is responsible for creating ports in openvswitch during booting/migrating instances.
I proposed already such patch in upstream: https://review.openstack.org/594118

Comment 10 James Hebden 2018-08-28 04:57:07 UTC
Thanks Slawomir for the additional work to close the loop on this. We had included the fixes that had been provided upstream for information purposes, and as Miguel has noted in the tracker, additional patches to nova/os-vif are required to close this out fully. Can you confirm if the upstream neutron patches will also be applied? My understanding of the situation is that both this, and your additional os-vif patch are required to fully close this out.

Comment 11 Slawek Kaplonski 2018-08-28 07:35:17 UTC
Hi James.
Unfortunately my patch proposed to os-vif will have to be modified and it will also require other patch in Neutron probably. We can't simply set this vlan tag always in os-vif as it breaks other Neutron backends (like networking-odl or dragonfly for example).
I will work on that and propose patch to neutron and then modify this one for os-vif.

Comment 12 James Hebden 2018-09-09 22:31:03 UTC
Thanks Slawomir, for the clarification, that makes sense. Thanks for your work on this.

Comment 23 Product Security DevOps Team 2021-07-06 16:40:20 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.