#1104488 live-boot: Segmentation fault when trying to mount filesystem.squashfs with filesystem.squashfs.verity and filesystem.squashfs.roothash

#1104488#5
Date:
2025-05-01 07:59:55 UTC
From:
To:
Dear Maintainer,

We have a live DVD based on Debian that we build inside a docker container
using mmdebstrap. The whole DVD builds reproducibly. Now we want to add secureboot
and dm-verity. Secureboot looks good, but we are strugling with dm-verity.

"veritysetup format" and "veritysetup verify" seem to work fine. But when
the system boots, I always get "segmentation faults" (for trixie) or "operation
not supported" (for bookworm) when it tries to mount the verity squashfs.

The full source can be found at https://github.com/AminaBank/livedeb/
To reproduce the error, just run:
git checkout feature/verity && make iso && make run

The error happens at:
https://salsa.debian.org/live-team/live-boot/-/blob/master/components/9990-overlay.sh?ref_type=heads#L179

I found the following in boot.log

Begin: Mounting "/run/live/medium/live/filesystem.squashfs" on "/run/live/rootfs/filesystem.squashfs" via "/dev/loop0" ... + return 0
+ mount -t squashfs -o ro,noatime -o 'verity.hashdevice=/dev/loop1' -o 'verity.roothashfile=/run/live/medium/live/filesystem.squashfs.roothash' -o 'verity.oncorruption=panic' /dev/loop0 /run/live/rootfs/filesystem.squashfs
Segmentation fault
+ panic 'Can not mount /dev/loop0 (/run/live/medium/live/filesystem.squashfs) on /run/live/rootfs/filesystem.squashfs'

#1104488#10
Date:
2025-06-01 13:09:09 UTC
From:
To:
Hello Richard,
I found the subject interesting so I started I tried to take a look.
It was possible to attach a "USB key" to the VM and generate a core file.
Examining the core leads to the below backtrace, and having
the function pointer crypt_deactivate_by_name being called while it
contains a NULL.

This function pointer seems to get filled in load_libcryptsetup_symbols,
unfortunately the initramsfs seems to be missing the file "libcryptsetup.so.12".

It would be nice if mount would have printed a warning about it,
and not crash, so probably this bug should be reassigned?

Kind regards,
Bernhard

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fa0f65862f7 in delete_veritydev (cxt=cxt@entry=0x55f33b86e9e0, hs=hs@entry=0x7fa0f65c06c0 <hookset_veritydev>, hsd=hsd@entry=0x55f33b86e480) at libmount/src/hook_veritydev.c:271
#2  0x00007fa0f658771a in delete_veritydev (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>, hsd=0x55f33b86e480) at libmount/src/hook_veritydev.c:262
#3  free_hookset_data (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>) at libmount/src/hook_veritydev.c:169
#4  hookset_deinit (cxt=0x55f33b86e9e0, hs=0x7fa0f65c06c0 <hookset_veritydev>) at libmount/src/hook_veritydev.c:212
#5  0x00007fa0f657e350 in mnt_context_deinit_hooksets (cxt=cxt@entry=0x55f33b86e9e0) at libmount/src/hooks.c:109
#6  0x00007fa0f657945f in mnt_context_mount (cxt=cxt@entry=0x55f33b86e9e0) at libmount/src/context_mount.c:1106
#7  0x000055f3373cbac3 in main (argc=<optimized out>, argv=<optimized out>) at sys-utils/mount.c:1107
(gdb) print hsd->dl_funcs.crypt_deactivate_by_name
$3 = (int (*)(struct crypt_device *, const char *, uint32_t)) 0x0