linux-kernel - Executable loading issues with erofs on arm?

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]

Message-ID: <38d43fae-1182-4155-9c5b-ffc7382d9917@siemens.com>
Date: Tue, 8 Jul 2025 14:41:54 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Gao Xiang <xiang@...nel.org>, Chao Yu <chao@...nel.org>,
 linux-erofs@...ts.ozlabs.org
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Executable loading issues with erofs on arm?

Hi all,

for some days, I'm trying to understand if we have an integration issue
with erofs or rather some upstream bug. After playing with various
parameters, it rather looks like the latter:

$ ls -l erofs-dir/
total 132
-rwxr-xr-x 1 1000 users 132868 Jul  8 10:50 dash
(from Debian bookworm)
$ mkfs.erofs -z lz4hc erofs.img erofs-dir/
mkfs.erofs 1.8.6 (trixie version, but same happens with bookworm 1.5)
Build completed.
------
Filesystem UUID: aae0b2f0-4ee4-4850-af49-3c1aad7fa30c
Filesystem total blocks: 17 (of 4096-byte blocks)
Filesystem total inodes: 2
Filesystem total metadata blocks: 1
Filesystem total deduplicated bytes (of source files): 0

Now I have 6.15-rc5 and a defconfig-close setting for the 32-bit ARM
target BeagleBone Black. When booting into init=/bin/sh, then running

# mount -t erofs /dev/mmcblk0p1 /mnt
erofs (device mmcblk0p1): mounted with root inode @ nid 36.
# /mnt/dash
Segmentation fault

I once also got this:

Alignment trap: not handling instruction 2b00 at [<004debc0>]
8<--- cut here ---
Unhandled fault: alignment exception (0x001) at 0x000004d9
[000004d9] *pgd=00000000
Bus error

All is fine if I
 - run the command once more
 - dump the file first (cat /mnt/dash > /dev/null; /mnt/dash)
 - boot a full Debian system and then mount & run the command
 - do not compress erofs

Also broken is -z zstd, so the decompression algorithm itself should not
be the reason. I furthermore tested older kernels as well, namely
stable-derived 6.1-cip and 6.12-cip, and those are equally affected.

Any ideas? I have CONFIG_EROFS_FS_DEBUG=y, but that does not trigger
anything. Is there anything I could instrument?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center