[PATCH] hash: fix strict aliasing UB in MurMur hash implementation

This was spotted when trying to upgrade the libseccomp fedora package to
version 2.6.0 in fedora rawhide. It comes with gcc 15 and LTO enabled by
default. When running the test 61-sim-transactions we get plenty of such
errors in valgrind:

==265507== Use of uninitialised value of size 8
==265507==    at 0x4096AD: _hsh_add (gen_bpf.c:599)
==265507==    by 0x40A557: UnknownInlinedFun (gen_bpf.c:2016)
==265507==    by 0x40A557: gen_bpf_generate (gen_bpf.c:2341)
==265507==    by 0x400CDE: UnknownInlinedFun (db.c:2685)
==265507==    by 0x400CDE: UnknownInlinedFun (db.c:2682)
==265507==    by 0x400CDE: UnknownInlinedFun (api.c:756)
==265507==    by 0x400CDE: UnknownInlinedFun (util.c:162)
==265507==    by 0x400CDE: UnknownInlinedFun (util.c:153)
==265507==    by 0x400CDE: main (61-sim-transactions.c:128)
==265507==  Uninitialised value was created by a stack allocation
==265507==    at 0x409590: _hsh_add (gen_bpf.c:573)

Investigating this a bit, it seems that because of LTO the MurMur hash
implementation is being inlined in _hsh_add. The two buffers data and
blocks to point at the same underlying data, but via incompatible type,
which is a strict aliasing violation. Instead, remove the getblock32
function and inline the copy with memcpy.

This is reproducible on a "fedora:rawhide" container (gcc 15) and using:
export CFLAGS='-O2 -flto=auto -ffat-lto-objects -g'

Signed-off-by: Romain Geissler <romain.geissler@amadeus.com>
Reviewed-by: Sam James <sam@gentoo.org>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: subject line tweak]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name hash_fix_strict_aliasing_UB_in_MurMur_hash_implementation.patch

[PATCH] api: fix seccomp_export_bpf_mem out-of-bounds read

*len is the length of the destination buffer, but program->blks is
probably not anywhere near that long.  It's already been checked above
that BPF_PGM_SIZE(program) is less than or equal to *len, so that's
the correct value to use here to avoid either reading or writing too
much.

I noticed this because tests/11-basic-basic_errors started failing on
musl after e797591 ("all: add seccomp_precompute() functionality").

Signed-off-by: Alyssa Ross <hi@alyssa.is>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Gbp-Pq: Name api_fix_seccomp_export_bpf_mem_out-of-bounds_read.patch

[PATCH] tests: remove the fuzzer from test 62-sim-arch_transactions

We can't reliably run the bpf-sim-fuzz tests on tests which manipulate
the filters arch/ABIs unless the filter is safe to run on all arch/ABIs,
which is more or less impossible.  Remove the bpf-sim-fuzz test section
in test #62 to work around this, just as we do with the other similar
tests.

Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
(cherry picked from commit 7db46d72f13c172b290818f624c2966bd0db5677)

Gbp-Pq: Name tests_remove_the_fuzzer_from_test_62-sim-arch_transactions.patch

python_single_version_externally_managed

Fix building with setuptools instead of distutils.

Gbp-Pq: Name python_single_version_externally_managed.patch

libseccomp (2.6.0-2) unstable; urgency=medium

  * Upload to unstable.
  * Disable valgrind unit tests, it's not stable enough.
  * Cherry-pick upstream fixes:
    - tests_remove_the_fuzzer_from_test_62-sim-arch_transactions.patch
    - hash_fix_strict_aliasing_UB_in_MurMur_hash_implementation.patch
    - api_fix_seccomp_export_bpf_mem_out-of-bounds_read.patch

[dgit import unpatched libseccomp 2.6.0-2]

Import libseccomp_2.6.0-2.debian.tar.xz

[dgit import tarball libseccomp 2.6.0-2 libseccomp_2.6.0-2.debian.tar.xz]

Import libseccomp_2.6.0.orig.tar.gz

[dgit import orig libseccomp_2.6.0.orig.tar.gz]