[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #4 from Mark Wielaard --- Note that packit doesn't use real hardware for various architectures but "container emulation" which causes various testcases to fail. Although in this case it seems it is overloading the host. Maybe we can tune down the number of concurrent request tested, see also: https://sourceware.org/pipermail/elfutils-devel/2021q4/thread.html#4488 If you have a better lower/upper bound or a way to test the limits of the machine. We do have somewhat better buildbot workers for various architectures here: https://builder.wildebeest.org/buildbot/#/builders?tags=elfutils -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 Mark Wielaard changed: What|Removed |Added Last reconfirmed||2021-12-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |mark at klomp dot org CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- > gelf_xlate.h:42:1: runtime error: member access within misaligned address > 0x7f019ba78032 for type 'struct Elf32_Phdr', which requires 4 byte alignment > [...] > #0 0x7f019d8fa5ea in Elf32_cvt_Phdr > /home/vagrant/elfutils/libelf/gelf_xlate.h:42 #1 0x7f019d8f85f3 in elf32_xlatetom /home/vagrant/elfutils/libelf/elf32_xlatetom.c:104 #2 0x7f019d827a76 in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:472 I have to think about this one. Should we try to handle unaligned access in the xlateto functions? Those functions make use of a lot of tricky macros, which depend on the types passed in. Or should we fix the called (dwfl_segment_report_module) to only pass correctly aligned buffers to the xlateto function? The xlate functions translate between big/little endian on-disk/in-memory Elf datastructure representations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
https://sourceware.org/bugzilla/show_bug.cgi?id=28685 --- Comment #2 from Evgeny Vereshchagin --- > Should we try to handle unaligned access in the xlateto functions? > Those functions make use of a lot of tricky macros, which depend on the > types passed in. > > Or should we fix the called (dwfl_segment_report_module) to only pass > correctly aligned buffers to the xlateto function? > I think it depends on how libelf is supposed to be used. If callers are expected to pass correctly aligned buffers it seems dwfl_segment_report_module should be fixed. But it seems that callers can sometimes assume that it should be fine to pass unaligned data. For example, (even though it has nothing to do with the xlateto functions) in one of libbpf issues it was pointed out that "I don't see anywhere the requirement that bytes passed to the elf_memory() should be aligned, so this does seem like libelf bug." -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/28710] New: ERROR: AddressSanitizer: SEGV on unknown address (on i386)
https://sourceware.org/bugzilla/show_bug.cgi?id=28710 Bug ID: 28710 Summary: ERROR: AddressSanitizer: SEGV on unknown address (on i386) Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: evvers at ya dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 13861 --> https://sourceware.org/bugzilla/attachment.cgi?id=13861&action=edit File triggering ASan OSS-Fuzz reported a stack-use-after-return on i386 in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=42264. It can be reproduced on an x86_64 Fedora machine by installing libc.i686, zlib-devel.i686 and libasan.i686 and building elfutils with -m32 ``` autoreconf -i -f ./configure --enable-maintainer-mode --disable-debuginfod --disable-libdebuginfod --without-bzlib --without-lzma --without-zstd --enable-sanitize-address CFLAGS="-m32 -g -O1" CXXFLAGS="-m32 -g -O1" make -j$(nproc) V=1 $ ASAN_OPTIONS=detect_stack_use_after_return=1 LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core ./oss-fuzz-42264 = ==13653==ERROR: AddressSanitizer: stack-use-after-return on address 0xf567a000 at pc 0xf7860e9b bp 0xffc10ae8 sp 0xffc10adc READ of size 4 at 0xf567a000 thread T0 #0 0xf7860e9a in dwfl_segment_report_module /home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:556 #1 0xf786e251 in _new.dwfl_core_file_report /home/vagrant/elfutils/libdwfl/core-file.c:559 #2 0x804b78a in parse_opt /home/vagrant/elfutils/src/stack.c:595 #3 0xf7457d4d in argp_parse (/lib/libc.so.6+0x11ed4d) #4 0x804caaa in main /home/vagrant/elfutils/src/stack.c:695 #5 0xf735e468 in __libc_start_call_main (/lib/libc.so.6+0x25468) #6 0xf735e549 in __libc_start_main_impl (/lib/libc.so.6+0x25549) #7 0x804a57b in _start (/home/vagrant/elfutils/src/stack+0x804a57b) Address 0xf567a000 is located in stack of thread T0 at offset 0 in frame #0 0xf786d0ef in dwfl_report_core_segments /home/vagrant/elfutils/libdwfl/core-file.c:126 This frame has 1 object(s): [32, 88) 'phdr_mem' (line 137) ``` -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] tests: integrate fuzz-dwfl-core into elfutils
Hi Evgeny,
On Sun, Dec 12, 2021 at 03:16:58PM +, Evgeny Vereshchagin via
Elfutils-devel wrote:
> The fuzz target was integrated into OSS-Fuzz in
> https://github.com/google/oss-fuzz/pull/6944 and since then it
> has been running there continously (uncovering various issues
> along the way). It's all well and good but since OSS-Fuzz
> is far from the elfutils repository it's unnecessarily hard
> to build the fuzz target locally, verify patches and more generally
> test new code to make sure that it doesn't introduce new issues (
> or reintroduce regressions). This patch aims to address all those
> issues by moving the fuzz target into the elfutils repository,
> integrating it into the testsuite and also providing a script
> that can be used to build full-fledged fuzzers utilizing libFuzzer.
> With this patch applied `make check` can be used to make sure
> that files kept in tests/fuzz-dwfl-core-corpus don't crash the
> code on various architecures.
> `--enable-sanitize-{address,undefined}` and/or `--enable-valgrind`
> can additionally be used to uncover issues like
> https://sourceware.org/bugzilla/show_bug.cgi?id=28685
> that don't always manifest themselves in simple segfaults. On top
> of all that now the fuzz target can be built and linked against
> libFuzzer locally by just running `./tests/build-fuzzers.sh`.
I like the general idea of this. I have been using src/stack as fuzz
target locally, but that is not ideal since it does too much. Having
specific fuzz target binaries is much better. I also like the idea of
making those fuzz-targets into regular testsuite targets. I am still
trying to wrap my head around the LLVMFuzzerTestOneInput and libfuzzer
requirements. I have experience with afl and honggfuzz which don't
have any external library requirement.
Also the LLVMFuzzerTestOneInput seems backwards. Shouldn't there be a
more generic name for a function that is called by a fuzzer? Maybe it
seems upside down because you translate from data stream to byte array
and back and then read in the reconstructed stream again. Once you
have the bytes you can simply call Elf *elf_memory (char *__image,
size_t __size), There is no need to first write out the image to disk
and then use a file descriptor to read it back in.
One thing I struggle with is the initial seed (corpus). It needs to be
as small as possible, but also contain some valid ELF (core) files, so
that the fuzzer knows which valid paths there are to try out. How did
you construct the initial corpus? I normally try to create at least
four (little|big) endian and (32|64) bit minimal valid ELF files, but
that is not always easy.
Finally I wonder if we cannot integrate the logic in build-fuzzers.sh
in the normal auto* build and create a "make fuzz" target that simply
uses CC=afl-gcc or CC=hfuzz-gcc and runs afl-fuzz or honggfuzz for a
couple of minutes if installed/detected by configure. The
build-fuzzers.sh script seems very specific to a google setup which
most people won't have locally and which seems somewhat tricky to
replicate on other CI builders.
Cheers,
Mark
Re: [PATCH] tests: integrate fuzz-dwfl-core into elfutils
Hi Mark, > Once you > have the bytes you can simply call Elf *elf_memory (char *__image, > size_t __size), There is no need to first write out the image to disk > and then use a file descriptor to read it back in. I think I should have mentioned in the commit message that the fuzz target came from systemd where elfutils is hidden behind functions receiving filenames and file descriptors and I wanted to cover that code. If I had switched to elf_memory I couldn't have covered the code paths used by systemd. I agree that in other fuzz targets I'm planning to add elf_memory should be used instead but it would be great if it was possible to keep this kind of systemd-specific target. > One thing I struggle with is the initial seed (corpus). It needs to be > as small as possible, but also contain some valid ELF (core) files, so > that the fuzzer knows which valid paths there are to try out. How did > you construct the initial corpus? I normally try to create at least > four (little|big) endian and (32|64) bit minimal valid ELF files, but > that is not always easy. I think the name of that directory is a misnomer because it isn't a seed corpus. I should have probably called it "fuzz-dwfl-core-crashes" or "fuzz-dwfl-core-regressions" because I simply put files that have triggered various issues there. I think initially I just added a valid core file used in the systemd testsuite and let OSS-Fuzz deal with the rest. More generally, with OSS-Fuzz I kind of use brute force to get corpora covering as much code as possible with as few files as possible and with them it usually takes about 5-10 seconds to figure out whether new bugs are introduced or not. Eventually those corpora can be downloaded, unpacked and used in test scripts. elfutils hasn't been there long enough to get links to those corpora but for example one of systemd corpora can be downloaded from https://storage.googleapis.com/systemd-backup.clusterfuzz-external.appspot.com/corpus/libFuzzer/systemd_fuzz-varlink/public.zip > Finally I wonder if we cannot integrate the logic in build-fuzzers.sh > in the normal auto* build and create a "make fuzz" target that simply > uses CC=afl-gcc or CC=hfuzz-gcc and runs afl-fuzz or honggfuzz for a > couple of minutes if installed/detected by configure. I think it's a good idea but I'm not sure how to make that all compatible with OSS-Fuzz. I'll try to figure out how to do that. > The > build-fuzzers.sh script seems very specific to a google setup which > most people won't have locally and which seems somewhat tricky to > replicate on other CI builders. I tried to decouple it from OSS-Fuzz as much as I could so in its current form to build the fuzzer with LibFuzzer it should be enough to install clang and run the script.
[PATCH] libdwfl: Make dwfl_segment_report_module aware of maximum Elf size
At the end of dwfl_segment_report_module we might try to read in
the whole contents described by a core file. To do this we first
allocate a zeroed block of memory that is as big as possible. The
core file however may describe much more loaded data than is actually
available in the Elf image. So pass the maximum size so we can
limit the amount of memory we reserve.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog| 8
libdwfl/core-file.c | 1 +
libdwfl/dwfl_segment_report_module.c | 5 +++--
libdwfl/libdwflP.h | 1 +
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index f849b816..21f3b6a4 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,11 @@
+2021-12-17 Mark Wielaard
+
+ * libdwflP.h (dwfl_segment_report_module): Add maxread argument.
+ * core-file.c (dwfl_core_file_report): Pass elf->maximum_size to
+ dwfl_segment_report_module.
+ * dwfl_segment_report_module.c (dwfl_segment_report_module): Add
+ maxread argument. Check file_trimmed_end against maxread.
+
2021-12-08 Mark Wielaard
* dwfl_segment_report_module.c (dwfl_segment_report_module): Add
diff --git a/libdwfl/core-file.c b/libdwfl/core-file.c
index 4e4c9b3c..b04d1d18 100644
--- a/libdwfl/core-file.c
+++ b/libdwfl/core-file.c
@@ -559,6 +559,7 @@ dwfl_core_file_report (Dwfl *dwfl, Elf *elf, const char
*executable)
int seg = dwfl_segment_report_module (dwfl, ndx, NULL,
&dwfl_elf_phdr_memory_callback, elf,
core_file_read_eagerly, elf,
+ elf->maximum_size,
note_file, note_file_size,
&r_debug_info);
if (unlikely (seg < 0))
diff --git a/libdwfl/dwfl_segment_report_module.c
b/libdwfl/dwfl_segment_report_module.c
index f323929e..73704efe 100644
--- a/libdwfl/dwfl_segment_report_module.c
+++ b/libdwfl/dwfl_segment_report_module.c
@@ -294,6 +294,7 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const char
*name,
void *memory_callback_arg,
Dwfl_Module_Callback *read_eagerly,
void *read_eagerly_arg,
+ size_t maxread,
const void *note_file, size_t note_file_size,
const struct r_debug_info *r_debug_info)
{
@@ -908,8 +909,8 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const char
*name,
/* The caller wants to read the whole file in right now, but hasn't
done it for us. Fill in a local image of the virtual file. */
- if (file_trimmed_end > SIZE_MAX)
- goto out;
+ if (file_trimmed_end > maxread)
+ file_trimmed_end = maxread;
void *contents = calloc (1, file_trimmed_end);
if (unlikely (contents == NULL))
diff --git a/libdwfl/libdwflP.h b/libdwfl/libdwflP.h
index 4344e356..7503a627 100644
--- a/libdwfl/libdwflP.h
+++ b/libdwfl/libdwflP.h
@@ -698,6 +698,7 @@ extern int dwfl_segment_report_module (Dwfl *dwfl, int ndx,
const char *name,
void *memory_callback_arg,
Dwfl_Module_Callback *read_eagerly,
void *read_eagerly_arg,
+ size_t maxread,
const void *note_file,
size_t note_file_size,
const struct r_debug_info *r_debug_info);
--
2.18.4
[PATCH] libdwfl: Make sure the note len increases each iteration
In dwfl_segment_report_module we have an overflow check when reading notes, but we could still not make any progress if the number of bytes read (len) didn't increase at all. Check len > last_len. Signed-off-by: Mark Wielaard --- libdwfl/ChangeLog| 5 + libdwfl/dwfl_segment_report_module.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog index 21f3b6a4..a1288d44 100644 --- a/libdwfl/ChangeLog +++ b/libdwfl/ChangeLog @@ -1,3 +1,8 @@ +2021-12-08 Mark Wielaard + + * dwfl_segment_report_module.c (dwfl_segment_report_module): Make + sure the note len increases each iteration. + 2021-12-17 Mark Wielaard * libdwflP.h (dwfl_segment_report_module): Add maxread argument. diff --git a/libdwfl/dwfl_segment_report_module.c b/libdwfl/dwfl_segment_report_module.c index 73704efe..cad1a9b3 100644 --- a/libdwfl/dwfl_segment_report_module.c +++ b/libdwfl/dwfl_segment_report_module.c @@ -559,7 +559,7 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const char *name, note_desc = notes + len; if (unlikely (filesz < len + nh->n_descsz -|| len < last_len +|| len <= last_len || len + nh->n_descsz < last_len)) break; -- 2.18.4
[COMMITTED] tests: Use /bin/sh instead of /bin/ls as always there binary
run-debuginfod-query-retry.sh would fail when /bin/ls wasn't available.
Use /bin/sh instead which really is always available.
GNU Guix doesn't have any other standard binary in /bin except for sh.
Signed-off-by: Mark Wielaard
---
tests/ChangeLog | 4
tests/run-debuginfod-query-retry.sh | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index 82061c6e..c97ed52e 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,7 @@
+2021-12-17 Mark Wielaard
+
+ * run-debuginfod-query-retry.sh: Use /bin/sh instead of /bin/ls.
+
2021-12-09 Frank Ch. Eigler
* debuginfod-subr.sh (xfail): New proc.
diff --git a/tests/run-debuginfod-query-retry.sh
b/tests/run-debuginfod-query-retry.sh
index c9192510..0cfdba92 100755
--- a/tests/run-debuginfod-query-retry.sh
+++ b/tests/run-debuginfod-query-retry.sh
@@ -25,7 +25,7 @@ unset VALGRIND_CMD
# set up tests for retrying failed queries.
retry_attempts=`(testrun env DEBUGINFOD_URLS=http://255.255.255.255/JUNKJUNK
DEBUGINFOD_RETRY_LIMIT=10 DEBUGINFOD_VERBOSE=1
DEBUGINFOD_CACHE_PATH=${PWD}/.client_cache \
-${abs_top_builddir}/debuginfod/debuginfod-find debuginfo /bin/ls ||
true) 2>&1 >/dev/null \
+${abs_top_builddir}/debuginfod/debuginfod-find debuginfo /bin/sh ||
true) 2>&1 >/dev/null \
| grep -c 'Retry failed query'`
if [ $retry_attempts -ne 10 ]; then
echo "retry mechanism failed."
--
2.18.4
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a new failure on builder elfutils-fedora-x86_64 while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/3/builds/880 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: Blamelist: Mark Wielaard BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #5 from Frank Ch. Eigler --- (In reply to Mark Wielaard from comment #4) > Note that packit doesn't use real hardware for various architectures but > "container emulation" which causes various testcases to fail. > > Although in this case it seems it is overloading the host. [...] Is there some way of finding out the host's actual limits? Can we detect that we're running in an unusually constricted environment and skip this test? ulimit -u? --- Comment #6 from Frank Ch. Eigler --- (In reply to Mark Wielaard from comment #4) > Note that packit doesn't use real hardware for various architectures but > "container emulation" which causes various testcases to fail. > > Although in this case it seems it is overloading the host. [...] Is there some way of finding out the host's actual limits? Can we detect that we're running in an unusually constricted environment and skip this test? ulimit -u? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 --- Comment #5 from Frank Ch. Eigler --- (In reply to Mark Wielaard from comment #4) > Note that packit doesn't use real hardware for various architectures but > "container emulation" which causes various testcases to fail. > > Although in this case it seems it is overloading the host. [...] Is there some way of finding out the host's actual limits? Can we detect that we're running in an unusually constricted environment and skip this test? ulimit -u? --- Comment #6 from Frank Ch. Eigler --- (In reply to Mark Wielaard from comment #4) > Note that packit doesn't use real hardware for various architectures but > "container emulation" which causes various testcases to fail. > > Although in this case it seems it is overloading the host. [...] Is there some way of finding out the host's actual limits? Can we detect that we're running in an unusually constricted environment and skip this test? ulimit -u? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to be flaky
https://sourceware.org/bugzilla/show_bug.cgi?id=28708 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |WAITING -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libdwfl: Make sure there is at least one dynamic entry
The buffer read in needs to contain room for at least one Elf32_Dyn or
Elf64_Dyn entry.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 5 +
libdwfl/link_map.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index f849b816..d4eee639 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,8 @@
+2021-12-16 Mark Wielaard
+
+ * link_map.c (dwfl_link_map_report): Make sure dyn_filesz / entsize is
+ non-zero.
+
2021-12-08 Mark Wielaard
* dwfl_segment_report_module.c (dwfl_segment_report_module): Add
diff --git a/libdwfl/link_map.c b/libdwfl/link_map.c
index 82df7b69..177ad9a5 100644
--- a/libdwfl/link_map.c
+++ b/libdwfl/link_map.c
@@ -1017,6 +1017,11 @@ dwfl_link_map_report (Dwfl *dwfl, const void *auxv,
size_t auxv_size,
in.d_size. The data might have been truncated. */
if (dyn_filesz > in.d_size)
dyn_filesz = in.d_size;
+ if (dyn_filesz / entsize == 0)
+ {
+ __libdwfl_seterrno (DWFL_E_BADELF);
+ return false;
+ }
void *buf = malloc (dyn_filesz);
Elf32_Dyn (*d32)[dyn_filesz / sizeof (Elf32_Dyn)] = buf;
Elf64_Dyn (*d64)[dyn_filesz / sizeof (Elf64_Dyn)] = buf;
--
2.30.2
[PATCH] libdwfl: Make sure there is at least one phdr
The buffer read in needs to contain room for at least one Phdr.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 4
libdwfl/link_map.c | 5 +
2 files changed, 9 insertions(+)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index d4eee639..8760b1ef 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,7 @@
+2021-12-16 Mark Wielaard
+
+ * link_map.c (dwfl_link_map_report): Make sure phnum is non-zero.
+
2021-12-16 Mark Wielaard
* link_map.c (dwfl_link_map_report): Make sure dyn_filesz / entsize is
diff --git a/libdwfl/link_map.c b/libdwfl/link_map.c
index 177ad9a5..c4f79f11 100644
--- a/libdwfl/link_map.c
+++ b/libdwfl/link_map.c
@@ -890,6 +890,11 @@ dwfl_link_map_report (Dwfl *dwfl, const void *auxv, size_t
auxv_size,
{
nbytes = in.d_size;
phnum = nbytes / phent;
+ if (phnum == 0)
+ {
+ __libdwfl_seterrno (DWFL_E_BADELF);
+ return false;
+ }
}
void *buf = malloc (nbytes);
Elf32_Phdr (*p32)[phnum] = buf;
--
2.30.2
[PATCH] libdwfl: Make sure note data is properly aligned.
In dwfl_segment_report_module the note data might not be properly
aligned. Check that it is before accessing the data directly.
Otherwise convert data so it is properly aligned.
Also fix NOTE_ALIGN4 and NOTE_ALIGN8 to work correctly with long
types.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog| 5 +
libdwfl/dwfl_segment_report_module.c | 5 -
libelf/ChangeLog | 5 +
libelf/libelfP.h | 4 ++--
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 8760b1ef..f18a0c45 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,8 @@
+2021-12-16 Mark Wielaard
+
+ * dwfl_segment_report_module.c (dwfl_segment_report_module): Check
+ note data is properly aligned.
+
2021-12-16 Mark Wielaard
* link_map.c (dwfl_link_map_report): Make sure phnum is non-zero.
diff --git a/libdwfl/dwfl_segment_report_module.c
b/libdwfl/dwfl_segment_report_module.c
index f323929e..2263e3cc 100644
--- a/libdwfl/dwfl_segment_report_module.c
+++ b/libdwfl/dwfl_segment_report_module.c
@@ -517,7 +517,10 @@ dwfl_segment_report_module (Dwfl *dwfl, int ndx, const
char *name,
assert (sizeof (Elf32_Nhdr) == sizeof (Elf64_Nhdr));
void *notes;
- if (ei_data == MY_ELFDATA)
+ if (ei_data == MY_ELFDATA
+ && (uintptr_t) data == (align == 8
+ ? NOTE_ALIGN8 ((uintptr_t) data)
+ : NOTE_ALIGN4 ((uintptr_t) data)))
notes = data;
else
{
diff --git a/libelf/ChangeLog b/libelf/ChangeLog
index 96059eff..617d97a5 100644
--- a/libelf/ChangeLog
+++ b/libelf/ChangeLog
@@ -1,3 +1,8 @@
+2021-12-16 Mark Wielaard
+
+ * libelfP.h (NOTE_ALIGN4): And with negative unsigned long.
+ (NOTE_ALIGN8): Likewise.
+
2021-12-15 Mark Wielaard
* elf_begin.c (get_shnum): Use offsetof to get field of unaligned
diff --git a/libelf/libelfP.h b/libelf/libelfP.h
index fc1aebec..2c6995bb 100644
--- a/libelf/libelfP.h
+++ b/libelf/libelfP.h
@@ -603,10 +603,10 @@ extern void __libelf_reset_rawdata (Elf_Scn *scn, void
*buf, size_t size,
/* Align offset to 4 bytes as needed for note name and descriptor data.
This is almost always used, except for GNU Property notes, which use
8 byte padding... */
-#define NOTE_ALIGN4(n) (((n) + 3) & -4U)
+#define NOTE_ALIGN4(n) (((n) + 3) & -4UL)
/* Special note padding rule for GNU Property notes. */
-#define NOTE_ALIGN8(n) (((n) + 7) & -8U)
+#define NOTE_ALIGN8(n) (((n) + 7) & -8UL)
/* Convenience macro. */
#define INVALID_NDX(ndx, type, data) \
--
2.30.2
