RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 798467 - libvirt doesn't validate a manually specified MAC address for a KVM guest
Summary: libvirt doesn't validate a manually specified MAC address for a KVM guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 782183
TreeView+ depends on / blocked
 
Reported: 2012-02-28 23:15 UTC by Nandini Chandra
Modified: 2018-12-01 18:48 UTC (History)
10 users (show)

Fixed In Version: libvirt-0.9.13-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 07:08:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0276 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2013-02-20 21:18:26 UTC

Description Nandini Chandra 2012-02-28 23:15:07 UTC 
Description of problem:
For KVM guests, it is required that the first 3 pairs in the MAC address of the Ethernet interface be of the sequence ’52:54:00’.When a MAC address is not manually specified,the MAC address generated by libvirt is always of the sequence '52:54:00'.However,libvirt doesn't validate a manually specified MAC address for a KVM guest against the valid range.

For eg:The 'mac' parameter in virt-install can be used to specify the MAC address of the Ethernet interface on the KVM guest.

Version-Release number of selected component (if applicable):
libvirt-0.9.4-23.el6_2.5.x86_64


How reproducible:
Always

Steps to Reproduce:
1.While installing a KVM guest through virt-install,use the 'mac' parameter to
specify a MAC address where the first 3 octets are not of the sequence ’52:54:00’.
2.libvirt allows guest Ethernet interfaces to have a MAC address where the first 3 octets are not of the sequence ’52:54:00’.
3.
  
Actual results:
libvirt doesn't validate a manually specified MAC address for a KVM guest

Expected results:
libvirt should validate a manually specified MAC address for a KVM guest against the vaild range and display an appropriate error message.

Additional info:
Comment 2 Dave Allan 2012-02-29 01:15:46 UTC 
There is no requirement that a KVM guest have a MAC with an OUI of 52:54:00 which is simply a 'locally administered' range that is used by qemu by convention and by libvirt's autogeneration mechanism.  In any event, libvirt does provides the mechanism to set whatever MAC the management application or the user specifies and should not second guess the user's choice.  This behavior is by design and is not a bug.
Comment 3 Nandini Chandra 2012-02-29 20:18:53 UTC 
Bug 616517 was fixed in libvirt-0_8_1-17_el6. 

With this fix,libvirt assigns explicit MAC address to tap devices.The MAC address of the tap devices is computed by using the MAC address of the guest NIC,but with the high byte set to 0xFE.

So,if for some reason,the MAC address of the guest NIC is something like this:
[root@vm ~]ifconfig | grep eth0
eth0      Link encap:Ethernet  HWaddr FE:28:DD:C5:0D:54  
Note that the MAC address of the guest NIC has been manually specified in this case.

libvirt would assign the exact same address to the tap device
[root@kvmhost ~]#ifconfig | grep -i FE:28:DD:C5:0D:54
vnet11    Link encap:Ethernet  HWaddr FE:28:DD:C5:0D:54  


Because of this conflict,the KVM guest is unable to connect to the network and the following error message is seen on the KVM host:

Dec  7 10:24:43 bwy005223100d kernel: vnet9: received packet with own address as source address
Dec  7 10:24:44 bwy005223100d kernel: vnet9: received packet with own address as source address
Comment 6 Laine Stump 2012-03-05 17:06:14 UTC 
I proposed this patch upstream:

https://www.redhat.com/archives/libvir-list/2012-March/msg00163.html

It logs an error and fails the domain start / device attach if it encounters a MAC address starting with 0xFE being attached to a bridge device. Is this a sufficient fix?
Comment 7 Laine Stump 2012-04-03 15:24:04 UTC 
BTW, the above patch was pushed upstream and is in libvirt-0.9.11:

commit 5d57104538297a7e5dab21f9b7ca8070b80c24fb
Author: Laine Stump <laine>
Date:   Sun Mar 4 19:21:16 2012 -0500

    util: fail attempts to use same mac address for guest and tap
   
    If a guest's tap device is created using the same MAC address the
    guest uses for its own network card (which connects to the tap
    device), the Linux kernel will log the following message and traffic
    will not pass:
    
     kernel: vnet9: received packet with own address as source address
    
    This patch disallows MAC addresses with a first byte of 0xFE, but only in
    the case that the MAC address is used for a guest interface that's
    connected by way of a standard tap device. (In other words, the
    validation is done at runtime at the same place the MAC address is
    modified for the tap device, rather than when mac address is parsed,
    the idea being that it is then we know for sure the address will be
    problematic.)
Comment 11 Laine Stump 2012-05-16 19:42:58 UTC 
Already upstream. so moving to POST
Comment 14 zhe peng 2012-07-25 03:24:15 UTC 
I can reproduce this with build:libvirt-0.9.10-16.el6.x86_64

verify with:
libvirt-0.9.13-3.el6.x86_64

step:
1: via virt-install to install a guest with specify a MAC address:FE:28:DD:C5:0D:54

#virt-install -n demo -r 1024 -f /var/lib/libvirt/images/demo.img -s 4 --mac FE:28:DD:C5:0D:54 --cdrom /dev/cdrom
got libvirt error:
libvirtError: unsupported configuration: Unable to use MAC address starting with reserved value 0xFE - 'FE:28:DD:C5:0D:54' -
verification passed.
Comment 15 errata-xmlrpc 2013-02-21 07:08:27 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html
Note You need to log in before you can comment on or make changes to this bug.