[bug] incorrect GPT entry validation?

[bug] incorrect GPT entry validation?

[Dave Reisner]

Hi,

A user reported problems with libblkid incorrectly reporting (or not
reporting) tags for some partitions on a GPT formatted disk. I was able
to reproduce it:

- created a 10G disk on a VM
- initialized it with GPT (using gdisk), created 5 entries
- formatted each of them with ext4

blkid correctly reads the first 2 entries on the disk, but then starts
reporting corrupted GPT entries (seen via LIBBLKID_DEBUG=0xffff):

https://dev.archlinux.org/~dreisner/blkid_bad.txt

It's interesting to note that blkid will _always_ read 2 entries before
reporting corruption, i.e.

# blkid -c /dev/null /dev/vdd{4,5,2}

This shows full info for /dev/vdd4 and /dev/vdd5, but nothing for
/dev/vdd2.

Commenting out the final crc validation in libblkid/src/partitions/gpt.c
and rebuilding lets blkid continue on and it happily prints everything:

https://dev.archlinux.org/~dreisner/blkid_no_validate.txt

Of course this is entirely wrong, but I'm not familiar at all with the
internals of libblkid or GPT to understand what's misbehaving.


As an aside, I was sadly unable to create the same layout using the
shiny new fdisk:

Command (m for help): g

Command (m for help): n
Partition number (1-128): 1
First sector (34-20971486, default 34):
Using default value 34
Last sector (34-20971486, default 20971486): 2G
Value out of range.
Last sector (34-20971486, default 20971486): +2G
Created partition 1

Command (m for help): n
Partition number (1-128): 2
First sector (4194305-20971486, default 4194305): +2G
Value out of range.
First sector (4194305-20971486, default 4194305): +1G
Value out of range.
First sector (4194305-20971486, default 4194305): +1M
Value out of range.

Cheers,
Dave

Re: [bug] incorrect GPT entry validation?

[Karel Zak]

On Sat, Nov 03, 2012 at 02:35:11PM -0400, Dave Reisner wrote:
> Hi,
> 
> A user reported problems with libblkid incorrectly reporting (or not
> reporting) tags for some partitions on a GPT formatted disk. I was able
> to reproduce it:
> 
> - created a 10G disk on a VM
> - initialized it with GPT (using gdisk), created 5 entries
> - formatted each of them with ext4
> 
> blkid correctly reads the first 2 entries on the disk, but then starts
> reporting corrupted GPT entries (seen via LIBBLKID_DEBUG=0xffff):
> 
> https://dev.archlinux.org/~dreisner/blkid_bad.txt

It would be nice to have the debug output.

Please, send me begin of the device:

    # dd if=/dev/vdd of=img count=1 bs=1Mib
    # gzip -9 img

> It's interesting to note that blkid will _always_ read 2 entries before
> reporting corruption, i.e.

Hmm... sounds like in-memory buffer corruption libblkid caches the
data from the device).

> # blkid -c /dev/null /dev/vdd{4,5,2}

Are you able to reproduce the bug by "blkid -p -o udev" ?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: [bug] incorrect GPT entry validation?

[Mantas Mikulėnas]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Mon, Nov 5, 2012 at 11:45 AM, Karel Zak <kzak@redhat.com> wrote:
> It would be nice to have the debug output.
>
> Please, send me begin of the device:
>
>     # dd if=/dev/vdd of=img count=1 bs=1Mib
>     # gzip -9 img

Attached as img.gz. (I reported this bug originally, on this partition table.)

> Are you able to reproduce the bug by "blkid -p -o udev" ?

Yes, still can reproduce it with `blkid -c /dev/null -p -o udev
/dev/sda*`. (Log attached.)

-- 
Mantas Mikulėnas

[-- Attachment #2: img.gz --]
[-- Type: application/x-gzip, Size: 9823 bytes --]

[-- Attachment #3: blkid.log.gz --]
[-- Type: application/x-gzip, Size: 4992 bytes --]

Re: [bug] incorrect GPT entry validation?

[Karel Zak]

On Sat, Nov 03, 2012 at 02:35:11PM -0400, Dave Reisner wrote:
> blkid correctly reads the first 2 entries on the disk, but then starts
> reporting corrupted GPT entries (seen via LIBBLKID_DEBUG=0xffff):

 We have two GPT headers... and the third pass have nothing
 to parse :-)

 This is the bug:

          swap_efi_guid(&e->unique_partition_guid);
          swap_efi_guid(&e->partition_type_guid);

 the "e" is persistent buffer.

 Fixed. Thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com