Bug 993973

Summary: lseek errors or possible data corruption due to integer overflow in metadata area handling while using lvmetad
Product: [Fedora] Fedora Reporter: Peter Rajnoha <prajnoha>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: high    
Version: 19CC: agk, bmarzins, bmr, dwysocha, heinzm, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: lvm2-2.02.98-11.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 994016 (view as bug list) Environment:
Last Closed: 2013-08-09 17:06:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter Rajnoha 2013-08-06 13:32:10 UTC 
When reading an info about MDAs from lvmetad, we need to use 64 bit
int to read the value of the offset/size, otherwise the value is
overflows and then it's used throughout!
    
This is dangerous if we're trying to write such metadata area then,
mostly visible if we're using 2 mdas where the 2nd one is at the end
of the underlying device and hence the value of the mda offset is
high enough to cause problems:
    
(the offset trimmed to value of 0 instead of 4096m, so we write
at the very start of the disk (or elsewhere if the offset has
some other value!)
    
    [1] raw/~ # lvcreate -s -l 100%FREE vg --virtualsize 4097m
      Logical volume "lvol0" created
    
    [1] raw/~ # pvcreate --metadatacopies 2 /dev/vg/lvol0
      Physical volume "/dev/vg/lvol0" successfully created
    
    [1] raw/~ # hexdump -n 512 /dev/vg/lvol0
    0000000 0000 0000 0000 0000 0000 0000 0000 0000
    *
    0000200
    
    [1] raw/~ # pvchange -u /dev/vg/lvol0
      Physical volume "/dev/vg/lvol0" changed
      1 physical volume changed / 0 physical volumes not changed
    
    [1] raw/~ # hexdump -n 512 /dev/vg/lvol0
    0000000 d43e d2a5 4c20 4d56 2032 5b78 4135 7225
    0000010 4e30 3e2a 0001 0000 0000 0000 0000 0000
    0000020 0000 0010 0000 0000 0000 0000 0000 0000
    0000030 0000 0000 0000 0000 0000 0000 0000 0000
    *
    0000200
    
    =======
    
(the offset overflows to undefined values which is far behind
the end of the disk)
    
    [1] raw/~ # lvcreate -s -l 100%FREE vg --virtualsize 100g
      Logical volume "lvol0" created
    
    [1] raw/~ # pvcreate --metadatacopies 2 /dev/vg/lvol0
      Physical volume "/dev/vg/lvol0" successfully created
    
    [1] raw/~ # pvchange -u /dev/vg/lvol0
      /dev/vg/lvol0: lseek 18446744073708503040 failed: Invalid argument
      /dev/vg/lvol0: lseek 18446744073708503040 failed: Invalid argument
      Failed to store physical volume "/dev/vg/lvol0"
      0 physical volumes changed / 1 physical volume not changed


The patch: https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=34d207d9b37edc2499dfff2c4809fecf72926416
Comment 1 Fedora Update System 2013-08-06 14:42:52 UTC 
lvm2-2.02.98-11.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/lvm2-2.02.98-11.fc19
Comment 2 Fedora Update System 2013-08-06 23:36:19 UTC 
Package lvm2-2.02.98-11.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-11.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14347/lvm2-2.02.98-11.fc19
then log in and leave karma (feedback).
Comment 3 Fedora Update System 2013-08-09 17:06:48 UTC 
lvm2-2.02.98-11.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.