On 26.08.2019 17:33, Rafał Miłecki wrote:
I noticed a bug in "block" tool behavior. It was providing inconsistent
UUIDs for my disks with NTFS partitions.
(...)
That bug was exposed by cache_load(0) vs. cache_load(1). Those calls
result in different order of buffer allocation in the
blkid_probe_get_buffer().
This problem is caused by:
1) blkid_probe_get_buffer() resuing buffer when possible
2) __probe_ntfs() reading multiple blocks
As you can probably guess any subsequent block ready can overwrite a
content of previously returned block content buffer. In __probe_ntfs()
case it's something like:
ns = blkid_probe_get_sb(...);
buf_mft = blkid_probe_get_buffer(...);
buf_mft = blkid_probe_get_buffer(...);
ns->volume_serial
If you take a look at blkid_probe_get_buffer() in the original project
(util-linux's libblkid) it's a bit more complicated:
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libblkid/src/probe.c#n640
Another user noticed the same bug and posted a workaround:
[PATCH] fstools: fix libblkid-tiny ntfs uuid detection
https://patchwork.ozlabs.org/patch/1157097/
Another example is vfat which cannot detect one of my partitions. It's
cased by probe_vfat():
1. Reading vfat superblock:
vs = blkid_probe_get_sb(pr, mag, struct vfat_super_block);
2. Reading while trying to get FAT entry:
buf = blkid_probe_get_buffer(pr, fat_entry_off, buf_size);
3. Trying to access vs data once it was corrupted:
fsinfo_sect = le16_to_cpu(vs->vs_fsinfo_sector);
This bug really requires a proper fix.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
