Bug 629204

Summary: libvirt didn't check ip range allocated by dhcp based on network mask
Product: [Community] Virtualization Tools Reporter: xhu
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: crobinso, jtomko, mshao, tools-bugs, xen-maint, yoyzhang
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-28 14:08:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description xhu 2010-09-01 09:16:54 UTC
Description of problem:
libvirt didn't check ip range allocated by dhcp

Version-Release number of selected component (if applicable):
kernel-2.6.32-66.el6.x86_64
libvirt-0.8.1-27.el6.x86_64
qemu-kvm-0.12.1.2-2.112.el6.x86_64


How reproducible:
everytime

Steps to Reproduce:
1.prepare the following network xml file:
<network>
  <name>testbr</name>
  <uuid>f3e2761f-e6c9-36eb-9108-2c95655aa31e</uuid>
  <forward mode='nat'/>
  <bridge name='testbr' stp='on' delay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.252'>
    <dhcp>
      <range start='192.168.100.2' end='192.168.100.6' />
    </dhcp>
  </ip>
</network>
2. define and start the above network
# virsh net-define net.xml 
Network testbr defined from net.xml

# virsh net-start  testbr 
Network testbr started

3. start a guest with the following xml:
<interface type='network'>
      <mac address='52:54:00:f5:aa:b2'/>
      <source network='testbr'/>
      <target dev='vnet3'/>
      <alias name='net1'/>
</interface>

  
Actual results:
After step 3, the guest can't get IP.

Expected results:
In step 2, there should check IP range allocated by DHCP based on networkmask

Additional info:

Comment 2 Ján Tomko 2015-07-28 14:08:35 UTC
Fixed upstream in 1.2.17:

commit 55ace7c4789c8a7408139460f4b639cee00e5125
Author:     Laine Stump <laine>
AuthorDate: 2015-05-26 15:44:24 -0400
Commit:     Laine Stump <laine>
CommitDate: 2015-06-02 12:40:07 -0400

    util: report all address range errors in virSocketAddrGetRange()
    
    There are now many more reasons that virSocketAddrGetRange() could
    fail, so it is much more informative to report the error there instead
    of in the caller. (one of the two callers was previously assuming
    success, which is almost surely safe based on the parsing that has
    already happened to the config by that time, but it still is nicer to
    account for an error "just in case")
    
    Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

git describe: v1.2.16-25-g55ace7c contains: v1.2.17-rc1~318

commit 1e334a0a000b70c8f0ab57d9fcaaa8cfc480759a
Author:     Laine Stump <laine>
AuthorDate: 2015-05-22 17:32:02 -0400
Commit:     Laine Stump <laine>
CommitDate: 2015-06-02 12:40:07 -0400

    network: validate DHCP ranges are completely within defined network
    
    virSocketAddrGetRange() has been updated to take the network address
    and prefix, and now checks that both the start and end of the range
    are within that network, thus validating that the entire range of
    addresses is in the network. For IPv4, it also checks that ranges to
    not start with the "network address" of the subnet, nor end with the
    broadcast address of the subnet (this check doesn't apply to IPv6,
    since IPv6 doesn't have a broadcast or network address)
    
    Negative tests have been added to the network update and socket tests
    to verify that bad ranges properly generate an error.
    
    This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=985653

git describe: v1.2.16-23-g1e334a0 contains: v1.2.17-rc1~320