Bug 994016 - 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 CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2 (Show other bugs)
7.0
All Linux
high Severity urgent
: rc
: ---
Assigned To: Peter Rajnoha
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-06 09:51 EDT by Peter Rajnoha
Modified: 2014-06-17 21:19 EDT (History)
14 users (show)

See Also:
Fixed In Version: lvm2-2.02.102-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 993973
Environment:
Last Closed: 2014-06-13 07:14:54 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:51:05 EDT
+++ This bug was initially created as a clone of Bug #993973 +++

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 2 Nenad Peric 2013-11-28 03:22:32 EST
Tested with 
lvm2-2.02.103-5.el7.x86_64
device-mapper-1.02.82-5.el7.x86_64

and could not reproduce the behavior in the opening comment. 

[root@virt-062 ~]# lvcreate -s -l 100%FREE vg --virtualsize 4097m
  Rounding up size to full physical extent 4.00 GiB
  Logical volume "lvol0" created
[root@virt-062 ~]# pvcreate --metadatacopies 2 /dev/vg/lvol0
  Physical volume "/dev/vg/lvol0" successfully created
[root@virt-062 ~]# hexdump -n 512 /dev/vg/lvol0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200
[root@virt-062 ~]# pvchange -u /dev/vg/lvol0
  Physical volume "/dev/vg/lvol0" changed
  1 physical volume changed / 0 physical volumes not changed
[root@virt-062 ~]# hexdump -n 512 /dev/vg/lvol0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200

[root@virt-062 lvm]# lvcreate -s -l 100%FREE vg --virtualsize 100g
  Logical volume "lvol0" created
[root@virt-062 lvm]# pvcreate --metadatacopies 2 /dev/vg/lvol0
  Physical volume "/dev/vg/lvol0" successfully created
[root@virt-062 lvm]# pvchange -u /dev/vg/lvol0
  Physical volume "/dev/vg/lvol0" changed
  1 physical volume changed / 0 physical volumes not changed
[root@virt-062 lvm]# hexdump -n 512 /dev/vg/lvol0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200


No errors were being reported. lvmetad was running

[root@virt-062 lvm]# systemctl status lvm2-lvmetad
lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled)
   Active: active (running) since Thu 2013-11-28 09:17:49 CET; 2min 16s ago
     Docs: man:lvmetad(8)
  Process: 27790 ExecStart=/usr/sbin/lvmetad (code=exited, status=0/SUCCESS)
 Main PID: 27791 (lvmetad)
   CGroup: /system.slice/lvm2-lvmetad.service
           └─27791 /usr/sbin/lvmetad


Marking Verified.
Comment 3 Ludek Smid 2014-06-13 07:14:54 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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