On Wed, Oct 07, 2026 at 07:28:30PM +0300, Abel Vesa wrote:
> With Clang 20 and CONFIG_FORTIFY_SOURCE, stacking Landlock domains can
> trigger a fortify panic in the handled_masks copy in inherit_ruleset():
[...]
> Based on next-20260930. Validated arm64 Landlock object builds with
> Clang 20 and GCC 14, with CONFIG_FORTIFY_SOURCE enabled, and checked the
> counter load in Clang-generated code. Not boot-tested.
Hi all, hit this issue yesterday on x86_64 (Framework 13, Meteor Lake),
v7.3-rc5 built with clang 21.1.8 and CONFIG_FORTIFY_SOURCE=y. I triggered
it simply by opening the printer settings on 26.04 (through xz, see below).
My build tree was recent v7.3-rc5, so I applied the patch, which was clean,
and then went through the repro steps after rebuilding. Everything works
as expected after 10-15 minutes of use - no crash, no other dmesg/journal
issues.
I hope you don't mind, but given how irritating it was to track down
the issue, I am including some of the Claude output below to help others
find the root cause more quickly if they hit it. I checked the
disassembly and ran the tests below myself on this machine.
<CLAUDE>
This is easy to hit on a stock desktop. xz 5.8 sandboxes itself with
nested landlock_restrict_self() calls, so on an unpatched clang build every
`xz -d` oopses:
memcpy: detected buffer overflow: 4 byte write of buffer size 0
WARNING: lib/string_helpers.c:1037 at __fortify_report+0x1f/0x60, CPU#6:
xz/9888
kernel BUG at lib/string_helpers.c:1044!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
RIP: 0010:__fortify_panic+0x9/0x10
Call Trace:
landlock_merge_ruleset+0x353/0x360
__se_sys_landlock_restrict_self+0x1bf/0x470
__x64_sys_landlock_restrict_self+0x16/0x30
On Ubuntu, simply opening GNOME Settings -> Printers runs the CUPS driver
helpers, which run xz. With kdump-tools installed (panic_on_oops=1), that
panics the machine. Nothing more than an unprivileged process is needed;
the reproducer below triggers it as a normal user:
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
for (i = 0; i < 2; i++) {
struct landlock_ruleset_attr a = {
.handled_access_fs = LANDLOCK_ACCESS_FS_MAKE_REG };
int fd = syscall(SYS_landlock_create_ruleset, &a, sizeof(a), 0);
syscall(SYS_landlock_restrict_self, fd, 0); /* i == 1 oopses */
close(fd);
}
The x86_64 codegen matches your arm64 analysis. Unpatched, with
num_layers at 0x24 and handled_masks at 0x28:
mov 0x28(%rbx),%esi # "count" read from child->handled_masks[0]
shl $0x2,%rsi
cmp %rdx,%rsi
jb <__fortify_panic>
With the patch, num_layers is at 0x40 and handled_masks at 0x44. The
count is loaded from the right field, and clang folds away the fortify
checks after the WARN_ON_ONCE(child->num_layers <= parent->num_layers):
mov 0x40(%r12),%edx
cmp %edx,0x40(%rbx)
...
call memcpy
Results after booting the patched kernel, with panic_on_oops=1 and
kdump loaded (the configuration that used to panic):
nested restrict reproducer: both layers succeed
echo hello | xz | xz -d: ok
lpinfo -m (CUPS -> xz): ok
fortify reports in dmesg: none; kernel not tainted
The layout change grows struct landlock_domain from 64 to 72 bytes. A
one-layer domain is still a kmalloc-96 allocation (68 bytes before, 76
after); only stacks of 7 or 8 layers move up to kmalloc-128. That seems
fine.
</CLAUDE>
Since this is reachable from unprivileged userspace on any clang +
FORTIFY_SOURCE build of 7.3-rc, it would be good to get this in before
v7.3 final.
Tested-by: Mike Bommarito <[email protected]>
