** Description changed: - I notified this bug with util-linux 2.20.1-5.1ubuntu20.2 and kernel - 3.13.0-39-generic (i386732 bit) with Ubuntu 14.04.1 LTS + [Impact] - I examined a 8gb sd-card image via loop device; parted reports: - # parted /dev/loop0 u b print - Modell: Loopback device (loop) - Festplatte /dev/loop0: 7822376960B - Sektorgröße (logisch/physisch): 512B/512B - Partitionstabelle: msdos + Partx is used to activate partitions on loopback devices. It is had a + bug causing it to overflow and wraparound at the 4 GB mark, causing it + to put the partitions in the wrong place giving access to the wrong + areas of the disk, which at best, renders the activated partitions + unusable, and at worst, may cause corrupt data to be written to disk. - Nummer Anfang Ende Größe Typ Dateisystem Flags - 1 4194304B 123000319B 118806016B primary LBA - 2 125829120B 7788822527B 7662993408B extended - 5 130023424B 264241151B 134217728B logical fat32 LBA - 6 268435456B 3245342719B 2976907264B logical ext4 - 7 3246391296B 3309305855B 62914560B logical fat32 LBA - 8 3313500160B 7785676799B 4472176640B logical ext4 - 3 7788822528B 7822376959B 33554432B primary ext4 + [Test Case] - Then I made partition devices: - # partx -a /dev/loop0 + truncate -s 6g img + sudo losetup /dev/loop0 img + sudo parted -s /dev/loop0 mklabel msdos mkpart primary ext2 5g 6g + cat /sys/block/loop0/loop0p1/start - This is what the kernel sees: - # cat /proc/partitions - major minor #blocks name + The value should be 9764864, which corresponds to 4999610368 bytes. + Instead the bug causes it to be 1376256, or 704643072 bytes. - 7 0 7639040 loop0 - 259 0 116021 loop0p1 - 259 1 1 loop0p2 - 259 2 32768 loop0p3 - 259 3 131072 loop0p5 - 259 4 2907136 loop0p6 - 259 5 61440 loop0p7 - 259 6 173056 loop0p8 + [Regression Potential] - First thing I noticed: the contents of partition 3 was different from - the one at the corresponding offset within the image file. Then I saw - - as you can see above - that also partition 8 is much smaller than - reported by parted. In fact, the difference between the partition size - as seen by the kernel (in 1024 byte blocks) to the one in the MBR is - exactly 4294967296 bytes or 2^32. This prompted me to check, if a - similar wraparound happened to the offset of partition 3, and compared - its content to that at offset mod 2^32 (3493855232) in the image file: - sha256sum of the next 100 sectors compared identical. - - It seems pretty obvious that partx uses 32-bit integers for offset and - size, and fails with sizes bigger than 4 gb. I think this bug is severe, - as partitions beyond 4 gb are mapped to a different area, and writing to - them overwrites data in other partitions. + None. The fix was simply to change the data type of the argument to + partx_add_partition from 32 bit ( unsigned long ) to 64 bit ( unsigned + long long ), which upstream did long ago.
** Summary changed: - partx wraps partition offset and length mod 2^32 (2^23 sectors) + SRU: partx wraps partition offset and length mod 2^32 (2^23 sectors) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1389321 Title: SRU: partx wraps partition offset and length mod 2^32 (2^23 sectors) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1389321/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
