Dear Maintainer,

I've encountered a bug where blkid (and udev) would mistake my xfs filesystem for a crypto_luks device which has the effect, for instance, that I cannot mount the disk by uuid anymore. This happened after I stored an image file of a LUKS2 device on said xfs filesystem. I've reported this issue upstream and it was acknowledged as a "blocker" bug [1].

I won't repeat the entire analysis here, but the gist is this:
When writing an image file of a LUKS2 device on an xfs filesystem, it's possible that the secondary header of the LUKS2 image may land at the same offset on the xfs device where blkid scans for secondary LUKS2 headers. Since LUKS and RAID take precedence over other filesystems in libblkid, blkid will incorrectly report that the device is a crypto_luks device, even though there is a valid filesystem header at the offset 0 and the secondary LUKS2 header is just part of a file on that filesystem.

Please note, the issue is not necessarily limited to xfs. It's just the filesystem that I encountered and investigated this on. Other filesystems might be affected depending on where (or at which offsets) their data blocks are stored on the device.

With a solution proposed by the upstream maintainer, I submitted (and tested) a small patch that fixes the issue. The patch has been merged upsream [2].

I would kindly ask that this fix will be backported to Debian stable, so I can mount my xfs filesystem as usual again. I have also verified that the patch applies to the current util-linux sources in Debian stable (with a small offset for one hunk).

Thank you!

Kind regards,

Timo

[1] https://github.com/util-linux/util-linux/issues/4170
[2] https://github.com/util-linux/util-linux/commit/3e60c1fe124dccd4e04d258ed7ff23f2d3ff4931.patch