linux-kernel - [BUG] Loopback devices with 4k logical block size are not automatically scanned for GPT partitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Aug 2018 16:30:05 -0700
From:   Andrew Jeddeloh <andrew.jeddeloh@...hat.com>
To:     linux-kernel@...r.kernel.org
Subject: [BUG] Loopback devices with 4k logical block size are not
 automatically scanned for GPT partitions

I think I found a bug with partition scanning/loopback devices with 4k
logical sectors. It affects 4.14.x and 4.17.x kernels (and presumably
others). I've also filed the bug on the kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=200749

Copied from the bugzilla report:

Loop devices with the logical sector size set to 4096 do not
autodetect partitions when attached. It may be the case for devices
with 4k logical sectors in general, but I do not have hardware to test
that. I have not tested with non-GPT disks.

I expect to see /dev/loopNpX devices appear when attaching a loopback
device with partitions, regardless of logical block size. With 4096
byte logical block size I only see /dev/loopN devices and no
/dev/loopNpX devices.

Steps to reproduce:
1) truncate -s 1G diskimg
2) losetup -fP --show -b 4096 diskimg
3) sgdisk -n 0:0:0 /dev/loopN # Other partitioning tools will probably
also work.
4) losetup -d /dev/loopN
5) losetup -fP --show -b 4096 diskimg

This happens reliably. I can reproduce it 100% of the time.

Running `sgdisk -p /dev/loopN` with trigger a partition scan and it
find the partitions correctly then, but they do not appear when
initially attached with `losetup -P`. Disk images with logical block
size 512 do appear correctly.

I've tested this with a Fedora 4.17.x kernel, my gentoo 4.17.x kernel
and a Container linux 4.14.x kernel; they all exhibit the same
behavior.

I don't see anything interesting in dmesg and udevadm monitor shows
there are no ADD uevents for the partition block devices until `sgdisk
-p /dev/loopN` is run.

Let me know if there's any other information you want.
Also please CC me in replies. I am not subscribed to the list in general

 - Andrew Jeddeloh