Re: [PATCH] landlock: Move the domain layer counter out of the anonymous union

[Mike Bommarito <michael.bommarito@gmail.com>]

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 <michael.bommarito@gmail.com>