Partition incorrectly identified as LUKS

Partition incorrectly identified as LUKS

[Anthony Rossomano]

OS: AlmaLinux 8.9
util-linux-2.32.1-44.el8_9.1.x86_64

LUKS image is stored on XFS partition. When secondary LUKS signature winds up at one of the offsets checked by libblkid partition then we have the side effects of partition reported with crypto_LUKS fstype, no by-label link created by udev, mount requires fstype, etc

Don’t think that this has been addressed upstream but need to confirm.

Also looking for input about possible workarounds.

Re: Partition incorrectly identified as LUKS

[Milan Broz]

On 12/11/25 4:20 PM, Anthony Rossomano wrote:
> LUKS image is stored on XFS partition. When secondary LUKS signature
> winds up at one of the offsets checked by libblkid partition then we
> have the side effects of partition reported with crypto_LUKS fstype,
> no by-label link created by udev, mount requires fstype, etc
> 
> Don’t think that this has been addressed upstream but need to
> confirm.
LUKS2 metadata contains offset, so it is not possible to detect
it on a wrong offset.

If it is detected on partition (secondary LUKS2 header),
it probably means that partition was not properly wiped before reformat.
(wipefs -a should wipe both LUKS2 headers)

Anyway, without the reproducer image it is just guessing.

Milan

Re: Partition incorrectly identified as LUKS

[Anthony Rossomano]

> On Dec 11, 2025, at 1:22 PM, Milan Broz <gmazyland@gmail.com> wrote:
> 
> On 12/11/25 4:20 PM, Anthony Rossomano wrote:
>> LUKS image is stored on XFS partition. When secondary LUKS signature
>> winds up at one of the offsets checked by libblkid partition then we
>> have the side effects of partition reported with crypto_LUKS fstype,
>> no by-label link created by udev, mount requires fstype, etc
>> Don’t think that this has been addressed upstream but need to
>> confirm.
> LUKS2 metadata contains offset, so it is not possible to detect
> it on a wrong offset.
> 
> If it is detected on partition (secondary LUKS2 header),
> it probably means that partition was not properly wiped before reformat.
> (wipefs -a should wipe both LUKS2 headers)
> 
> Anyway, without the reproducer image it is just guessing.
> 
> Milan
> 
Make sure we’re on the same page. This partition is properly wiped and formatted as XFS. There are LUKS encrypted squashfs image files stored in the partition. These images are updated periodically. The issue occurs when secondary LUKS signature in one of the image files winds up at offset on disk checked by libblkid. 

Tony

Re: Partition incorrectly identified as LUKS

[Milan Broz]

On 12/12/25 12:24 AM, Anthony Rossomano wrote:
> Make sure we’re on the same page. This partition is properly wiped
> and formatted as XFS. There are LUKS encrypted squashfs image files
> stored in the partition. These images are updated periodically. The
> issue occurs when secondary LUKS signature in one of the image files
> winds up at offset on disk checked by libblkid.

This just cannot happen until there is a bug in libblkid
(which should check offset) or something different happens.
The offset checking patch was added later, perhaps your distro did not backport the patch.

LUKS1 must be on offset 0.

LUKS2 is designed exactly to prevent this to happen by checking
header offset in on expected location form device start.

If upstream util-linux misdetects LUKS, then please send a testing image somewhere.

Thanks,
Milan