From: "Sam James" <sam@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] repo/gentoo:master commit in: sys-libs/libseccomp/, sys-libs/libseccomp/files/
Date: Wed, 19 Mar 2025 02:17:59 +0000 (UTC) [thread overview]
Message-ID: <1742350632.78093ece632bf44fccff975a3e382f7a82d9330d.sam@gentoo> (raw)
commit: 78093ece632bf44fccff975a3e382f7a82d9330d
Author: Sam James <sam <AT> gentoo <DOT> org>
AuthorDate: Wed Mar 19 02:16:17 2025 +0000
Commit: Sam James <sam <AT> gentoo <DOT> org>
CommitDate: Wed Mar 19 02:17:12 2025 +0000
URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=78093ece
sys-libs/libseccomp: more correctness fixes
* Use latest (and merged) version of aliasing patch
* Add another patch for out of bounds access (shows up as musl test failure)
Signed-off-by: Sam James <sam <AT> gentoo.org>
.../files/libseccomp-2.6.0-aliasing.patch | 50 ++++++++++++++++------
.../libseccomp/files/libseccomp-2.6.0-bounds.patch | 38 ++++++++++++++++
...-2.6.0-r1.ebuild => libseccomp-2.6.0-r2.ebuild} | 3 +-
3 files changed, 77 insertions(+), 14 deletions(-)
diff --git a/sys-libs/libseccomp/files/libseccomp-2.6.0-aliasing.patch b/sys-libs/libseccomp/files/libseccomp-2.6.0-aliasing.patch
index f946dc468822..f1f13454c890 100644
--- a/sys-libs/libseccomp/files/libseccomp-2.6.0-aliasing.patch
+++ b/sys-libs/libseccomp/files/libseccomp-2.6.0-aliasing.patch
@@ -1,9 +1,9 @@
-https://github.com/seccomp/libseccomp/pull/459
+https://github.com/seccomp/libseccomp/commit/84005ecc603fd0186188c4113452fd8e8a0c9bb3
-From e6904da422e68031b0237c1e005fc5e98c12e2cf Mon Sep 17 00:00:00 2001
+From 84005ecc603fd0186188c4113452fd8e8a0c9bb3 Mon Sep 17 00:00:00 2001
From: Romain Geissler <romain.geissler@amadeus.com>
Date: Tue, 18 Feb 2025 22:29:05 +0000
-Subject: [PATCH] Fix strict aliasing UB in MurMur hash implementation.
+Subject: [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
@@ -24,20 +24,26 @@ errors in valgrind:
==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 way we call getblock32
-with the explicit cast to const uint32_t* is a strict aliasing
-violation.
+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 614530bc8b3c9f49aa59d7eaef4863b746504c23)
---
- src/hash.c | 8 ++------
- 1 file changed, 2 insertions(+), 6 deletions(-)
+ src/hash.c | 12 +++---------
+ 1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/hash.c b/src/hash.c
-index 4435900f..301abfc9 100644
+index 4435900f..01ff9399 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -12,15 +12,11 @@
@@ -57,13 +63,31 @@ index 4435900f..301abfc9 100644
static inline uint32_t rotl32(uint32_t x, int8_t r)
{
return (x << r) | (x >> (32 - r));
-@@ -56,7 +52,7 @@ uint32_t hash(const void *key, size_t length)
+@@ -41,7 +37,6 @@ static inline uint32_t fmix32(uint32_t h)
+ uint32_t hash(const void *key, size_t length)
+ {
+ const uint8_t *data = (const uint8_t *)key;
+- const uint32_t *blocks;
+ const uint8_t *tail;
+ const int nblocks = length / 4;
+ const uint32_t c1 = 0xcc9e2d51;
+@@ -54,9 +49,8 @@ uint32_t hash(const void *key, size_t length)
+ uint32_t h1 = 0;
+
/* body */
- blocks = (const uint32_t *)(data + nblocks * 4);
+- blocks = (const uint32_t *)(data + nblocks * 4);
for(i = -nblocks; i; i++) {
- k1 = getblock32(blocks, i);
-+ memcpy(&k1, &blocks[i], sizeof(uint32_t));
++ memcpy(&k1, data + (nblocks + i) * sizeof(uint32_t), sizeof(uint32_t));
k1 *= c1;
k1 = rotl32(k1, 15);
-
+@@ -68,7 +62,7 @@ uint32_t hash(const void *key, size_t length)
+ }
+
+ /* tail */
+- tail = (const uint8_t *)(data + nblocks * 4);
++ tail = data + nblocks * sizeof(uint32_t);
+ switch(length & 3) {
+ case 3:
+ k2 ^= tail[2] << 16;
diff --git a/sys-libs/libseccomp/files/libseccomp-2.6.0-bounds.patch b/sys-libs/libseccomp/files/libseccomp-2.6.0-bounds.patch
new file mode 100644
index 000000000000..3f53cd7b1f28
--- /dev/null
+++ b/sys-libs/libseccomp/files/libseccomp-2.6.0-bounds.patch
@@ -0,0 +1,38 @@
+https://github.com/seccomp/libseccomp/commit/dd759e8c4f5685b526638fba9ec4fc24c37c9aec
+
+From dd759e8c4f5685b526638fba9ec4fc24c37c9aec Mon Sep 17 00:00:00 2001
+From: Alyssa Ross <hi@alyssa.is>
+Date: Thu, 13 Feb 2025 12:05:17 +0100
+Subject: [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>
+(imported from commit e8dbc6b555fb936bdfb8ab86f9a45fda96a8b7a2)
+---
+ src/api.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/api.c b/src/api.c
+index adccef32..65a277a4 100644
+--- a/src/api.c
++++ b/src/api.c
+@@ -786,7 +786,7 @@ API int seccomp_export_bpf_mem(const scmp_filter_ctx ctx, void *buf,
+ if (BPF_PGM_SIZE(program) > *len)
+ rc = _rc_filter(-ERANGE);
+ else
+- memcpy(buf, program->blks, *len);
++ memcpy(buf, program->blks, BPF_PGM_SIZE(program));
+ }
+ *len = BPF_PGM_SIZE(program);
+
+
diff --git a/sys-libs/libseccomp/libseccomp-2.6.0-r1.ebuild b/sys-libs/libseccomp/libseccomp-2.6.0-r2.ebuild
similarity index 97%
rename from sys-libs/libseccomp/libseccomp-2.6.0-r1.ebuild
rename to sys-libs/libseccomp/libseccomp-2.6.0-r2.ebuild
index cbdd8dc79a61..ef1c9999b334 100644
--- a/sys-libs/libseccomp/libseccomp-2.6.0-r1.ebuild
+++ b/sys-libs/libseccomp/libseccomp-2.6.0-r2.ebuild
@@ -48,7 +48,8 @@ PATCHES=(
"${FILESDIR}"/libseccomp-2.6.0-python-shared.patch
"${FILESDIR}"/libseccomp-2.5.3-skip-valgrind.patch
"${FILESDIR}"/${P}-drop-bogus-test.patch
- "${FILESDIR}"/${PN}-2.6.0-aliasing.patch
+ "${FILESDIR}"/${P}-aliasing.patch
+ "${FILESDIR}"/${P}-bounds.patch
)
src_prepare() {
next reply other threads:[~2025-03-19 2:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 2:17 Sam James [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-03-10 0:15 [gentoo-commits] repo/gentoo:master commit in: sys-libs/libseccomp/, sys-libs/libseccomp/files/ Sam James
2024-04-13 17:11 Mike Gilbert
2022-10-30 9:43 Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1742350632.78093ece632bf44fccff975a3e382f7a82d9330d.sam@gentoo \
--to=sam@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox