seccomp
/
libseccomp
/
13912721775
/
1
89%
main: 89%
main: 89%
|
Ran
|
Files
27
|
Run time
0s
|
Badge
Embed ▾
README BADGES
|
coverage: 90.239% (-0.01%) from 90.252%
push
github
pcmoorehash: 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> (imported from commit 614530bc8)
2718 of 3012 relevant lines covered (90.24%)
291703.37 hits per line
