touch-packages team mailing list archive

[Phillip Susi <psusi@xxxxxxxxxx>]

** 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
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1389321

Title:
  SRU: partx wraps partition offset and length mod 2^32 (2^23 sectors)

Status in “util-linux” package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  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.

  [Test Case]

  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

  The value should be 9764864, which corresponds to 4999610368 bytes.
  Instead the bug causes it to be 1376256, or 704643072 bytes.

  [Regression Potential]

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1389321/+subscriptions