RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 994016 - 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 CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: All
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 13:51 UTC by Peter Rajnoha
Modified: 2023-03-08 07:26 UTC (History)
14 users (show)

Fixed In Version: lvm2-2.02.102-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 993973
Environment:
Last Closed: 2014-06-13 11:14:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Peter Rajnoha 2013-08-06 13:51:05 UTC 
+++ 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 08:22:32 UTC 
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 11:14:54 UTC 
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.