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

[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