Bug 993973 - lseek errors or possible data corruption due to integer overflow in metadata area handling while using lvmetad
lseek errors or possible data corruption due to integer overflow in metadata ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
19
All Linux
high Severity urgent
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-06 09:32 EDT by Peter Rajnoha
Modified: 2013-08-09 13:06 EDT (History)
11 users (show)

See Also:
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 13:06:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Rajnoha 2013-08-06 09:32:10 EDT
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 10:42:52 EDT
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 19:36:19 EDT
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 13:06:48 EDT
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.

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