Hi,
I was trying to push 2.4.2 to Ubuntu and after the few cleanups we had in 2.4.1->2.4.2 that looked pretty good at first. But When the extended checks kicked in I reliably found the systemd self-tests breaking on i386 and s390x.
For what it is worth - they worked reliable on x86-64, armhf, arm64 and ppc64el.

I know that there were related systemd fixups but those are not strictly required since our fix triggered by my chrony tests.

After further debugging of the testcase I found that of the many that systemd runs all kinds of activity around shmat seems to have changed.

The number resolves to 397 with old and new seccomp, but fails with version 2.4.2

arch x86: SCMP_SYS(shmat) = 397
...
Failed to add shmat() rule for architecture x86, skipping: Invalid argument

I was going back and forth and isolated the test more and more to now have reached a minimal test program that on i386 as well as s390x reliable works/fails with 2.4.1/2.4.2.

$ cat > test-seccomp-shmat.c << EOF
#include <linux/seccomp.h>

#include <errno.h>
#include <seccomp.h>
#include <stdio.h>

#include <sys/shm.h>

/*
 * Test issues with libseccomp 2.4.1 -> 2.4.2
 * Derived from systemd testcase test_memory_deny_write_execute_shmat
 * which fails to install shmat rules with 2.4.2 on i386 and s390x
 */

int main()
{
   int shmat_syscall = -1;
   int rc = -1;
   scmp_filter_ctx ctx;

   ctx = seccomp_init(SCMP_ACT_ALLOW);
   if (ctx == NULL)
       return -1;

   shmat_syscall = SCMP_SYS(shmat);
   printf("SCMP_SYS(shmat) = %d\n", shmat_syscall);

   rc = seccomp_rule_add_exact(ctx, SCMP_ACT_ERRNO(EPERM), shmat_syscall, 1, SCMP_A2(SCMP_CMP_MASKED_EQ, SHM_EXEC, SHM_EXEC));
   printf("Rule installed RC = %d\n", rc);

   return 0;
}
EOF

Then build with:

$ gcc -Wall test-seccomp-shmat.c -o test-seccomp-shmat -lseccomp

Tests on i386 with the test I pasted above:

2.4.1:
./test-seccomp-shmat
SCMP_SYS(shmat) = 397
Rule installed RC = 0

2.4.2
./test-seccomp-shmat
SCMP_SYS(shmat) = 397
Rule installed RC = -22

s390x looks identical to the i386 output

Note: rebuilding on new libseccomp2 2.4.2 does not change this behavior

Now I'm wondering, is that a yet undiscovered issue in libseccomp 2.4.2 and if so what could it be?
Or if you can clearly state that this is right and should never have worked could you outline why it affects just i386 and s390x and how systemd (see the related systemd test / code here) would need to adapt so that I can start a discussion there?

P.S. kernels used are Ubuntus 5.3.0-18-generic in all tests