Bug 993973 - lseek errors or possible data corruption due to integer overflow in metadata area handling while using lvmetad
Summary: lseek errors or possible data corruption due to integer overflow in metadata ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 19
Hardware: All
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Peter Rajnoha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 13:32 UTC by Peter Rajnoha
Modified: 2013-08-09 17:06 UTC (History)
11 users (show)

Fixed In Version: lvm2-2.02.98-11.fc19
Clone Of:
: 994016 (view as bug list)
Environment:
Last Closed: 2013-08-09 17:06:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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