[obv] [patch] debuginfod-client memory hygiene
Planning to commit this shortly:
commit a71bac67f4705b84368b71f5ece54deedaa1abf1 (HEAD -> master1)
Author: Frank Ch. Eigler
Date: Tue Feb 18 22:09:12 2025 -0500
debuginfod-client: correct invalid free() in failed ima path
debuginfod-find with a failed signature configuration was found on f41
glibc (2.40) to sometimes leave invalid addresses in a sscanf("%ms", &ptr)
pointer in case of error, leading to an invalid free() during cleanup.
We now clear that ptr manually, making valgrind happy. Unclear why this
hasn't shown up in testsuite testing.
==1098106== Invalid free() / delete / delete[] / realloc()
==1098106==at 0x4844B83: free (vg_replace_malloc.c:989)
==1098106==by 0x49647A2: ??? (in /usr/lib64/libdebuginfod-0.192.so)
==1098106==by 0x401528: main (debuginfod-find.c:209)
==1098106== Address 0xc8 is not stack'd, malloc'd or (recently) free'd
Signed-off-by: Frank Ch. Eigler
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index d89beae93ea1..4152b06a135f 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -1599,6 +1599,7 @@ debuginfod_validate_imasig (debuginfod_client *c, int fd)
if (!hdr_ima_sig || 1 != sscanf(hdr_ima_sig +
strlen("x-debuginfod-imasignature:"), "%ms", &sig_buf))
{
rc = -ENODATA;
+ sig_buf = NULL; // f41 glibc may litter here in case of sscanf error
goto exit_validate;
}
if (strlen(sig_buf) > MAX_SIGNATURE_SIZE) // reject if too long
[Bug tools/32657] eu-readelf SEGV (buffer over read) in print_string_section (src/readelf.c:13363)
https://sourceware.org/bugzilla/show_bug.cgi?id=32657 --- Comment #2 from Mark Wielaard --- Note that someone created CVE-2025-1372 for this bug without following our SECURITY policy: https://sourceware.org/cgit/elfutils/tree/SECURITY This is NOT a security issue according to our policy: Since most elfutils tools are run in short-lived, local, interactive, development context rather than remotely "in production", we generally treat malfunctions as ordinary bugs rather than security vulnerabilities. We request that people who report suspected security vulnerabilities report them through the contacts in our SECURITY policy and not through non-affiliated CNAs. -- You are receiving this mail because: You are on the CC list for the bug.
debuginfod - IMA crypto enforcement status
Hi - Having upgraded debuginfod.elfutils.org's server to a more modern distro, this machine now can handle the IMA crypto extensions we added to debuginfod not too long ago. It federates to the same debuginfod servers as before, but for those that show "yes" in the "IMA" column, it now applies "ima:enforcing" mode. In theory, this means that users can rely on it taking greater care to validate its upstream downloads. In practice, users probably should *not* use ima:enforcing mode against debuginfod.elfutils.org itself, because some of its upstreams do not have IMA stuff at all (.deb and other formats), and it cannot yet consistently relay IMA signatures to clients (for cached objects PR31862). Baby steps! Clients are welcome to experiment with ima:enforcing mode connections directly to upstream servers marked "yes" in the IMA column of the public debuginfod servers list, e.g.: % export DEBUGINFOD_URLS="ima:enforcing https://debuginfod.fedoraproject.org/"; % gdb /bin/ls [...] See also: https://sourceware.org/elfutils/Debuginfod.html https://sourceware.org/bugzilla/show_bug.cgi?id=30978 https://sourceware.org/bugzilla/show_bug.cgi?id=31842 https://sourceware.org/bugzilla/show_bug.cgi?id=31862 https://sourceware.org/bugzilla/show_bug.cgi?id=32318 - FChE
[Bug libdw/32713] New: elfutils fails to symbolize core dumps created by Linux 6.12+
https://sourceware.org/bugzilla/show_bug.cgi?id=32713
Bug ID: 32713
Summary: elfutils fails to symbolize core dumps created by
Linux 6.12+
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libdw
Assignee: unassigned at sourceware dot org
Reporter: michael+sourceware at stapelberg dot ch
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Hey folks, thanks for maintaining elfutils!
I noticed that on my Linux machine, core dumps collected by systemd-coredump(8)
do no longer show symbol names in the backtrace displayed by 'coredumpctl
info'.
Digging deeper, the issue is unrelated to systemd-coredump and can be
reproduced by calling eu-stack directly, too.
I used the following example program:
% echo 'int main() { char *no = 0; *no = 0x23; }' > segfault.c
% gcc -g -o segfault segfault.c -Wall -static
You can find the compiled output at
https://t.zekjur.net/2025-02-17-elfutils/segfault (just in case).
When I let this program crash on Linux 6.13, I get a core dump like
https://t.zekjur.net/2025-02-17-elfutils/core.segfault.1000.6158dd3b52af4b8384c103a8a336fc02.2913783.173980684300.zst
When I let this program crash on Linux 6.1, I get a core dump like
https://t.zekjur.net/2025-02-17-elfutils/core.segfault.0.8f168ad538ed480eab20ebbab491d953.1079959.173980544400.zst
(You can easily tell the two apart by the .0. vs. .1000. uid in the front of
the filename.)
Now, when I check with elfutils 0.190, elfutils 0.192 or
elfutils-0.192-42gb16f441c from git (current git HEAD), the coredump from Linux
6.1 can be symbolized; the one from Linux 6.13 cannot:
% eu-stack --version
eu-stack (elfutils) 0.190
Copyright (C) 2023 The elfutils developers
