* [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
@ 2021-12-11 21:32 evvers at ya dot ru
2021-12-17 9:34 ` [Bug libelf/28685] " mark at klomp dot org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-11 21:32 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
Bug ID: 28685
Summary: UBSan: member access within misaligned address
0x7ff316818032 for type 'struct Elf32_Phdr'
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libelf
Assignee: unassigned at sourceware dot org
Reporter: evvers at ya dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 13845
--> https://sourceware.org/bugzilla/attachment.cgi?id=13845&action=edit
File triggering an "alignment" check
Trying to integrate the fuzz target into the test suite in
https://github.com/evverx/elfutils/pull/49, I noticed that it triggered the
"alignment" check in both gcc and clang (which I think is a bug because
`--enable-sanitize-undefined` explicitly turns off misaligned access). It can
be reproduced by building elfutils with UBSan and passing the attachment to
`./src/stack`:
```
autoreconf -i -f
./configure --enable-maintainer-mode --enable-sanitize-undefined CFLAGS='-g -O1
-fno-omit-frame-pointer' CXXFLAGS='-g -O1 -fno-omit-frame-pointer'
make -j$(nproc) V=1
UBSAN_OPTIONS=print_stacktrace=1:print_summary=1
LD_LIBRARY_PATH="./libelf:./libdw" ./src/stack --core ../oss-fuzz-41575
$ UBSAN_OPTIONS=print_stacktrace=1:print_summary=1
LD_LIBRARY_PATH="./libelf:./libdw" ./src/stack --core ../oss-fuzz-41575
gelf_xlate.h:42:1: runtime error: member access within misaligned address
0x7f019ba78032 for type 'struct Elf32_Phdr', which requires 4 byte alignment
0x7f019ba78032: note: pointer points here
2b 00 48 00 00 00 00 10 00 ff ff 7f 45 4c 46 01 01 01 0c 00 ff 00 00 00 00
00 00 04 00 3e ff 00
^
#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
#3 0x7f019d82c6db in _new.dwfl_core_file_report
/home/vagrant/elfutils/libdwfl/core-file.c:559
#4 0x402b0f in parse_opt /home/vagrant/elfutils/src/stack.c:595
#5 0x7f019ca7d471 in argp_parse (/lib64/libc.so.6+0x11e471)
#6 0x403d98 in main /home/vagrant/elfutils/src/stack.c:695
#7 0x7f019c98c55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#8 0x7f019c98c60b in __libc_start_main_impl (/lib64/libc.so.6+0x2d60b)
#9 0x4024c4 in _start (/home/vagrant/elfutils/src/stack+0x4024c4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gelf_xlate.h:42:1 in
```
Interestingly, judging by
https://copr-be.cloud.fedoraproject.org/results/packit/evverx-elfutils-49/fedora-rawhide-i386/03030724-elfutils/builder-live.log.gz
(where I ran the unit tests on i386) the file simply crashed the fuzz target
there
```
FAIL: run-fuzz-dwfl-core.sh
===========================
...
StandaloneFuzzTargetMain: running 1 inputs
Running:
/builddir/build/BUILD/elfutils-0.186/tests/fuzz-dwfl-core-corpus/oss-fuzz-41575
timeout: the monitored command dumped core
./test-subr.sh: line 84: 20674 Segmentation fault
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
*** failure in
/builddir/build/BUILD/elfutils-0.186/tests/fuzz-dwfl-core-corpus/oss-fuzz-41575
FAIL run-fuzz-dwfl-core.sh (exit status: 1)
+ false
error: Bad exit status from /var/tmp/rpm-tmp.P3WRAR (%check)
```
On OSS-Fuzz (on x86_64) that file triggered an "oom" reported in
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41575
```
Running:
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/oom-fa37b37eafe95a0ed4ef155ccb7f8178f177061d
==9982== ERROR: libFuzzer: out-of-memory (malloc(4294971391))
To change the out-of-memory limit use -rss_limit_mb=<N>
#0 0x52f411 in __sanitizer_print_stack_trace
/src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
#1 0x470a38 in fuzzer::PrintStackTrace() cxa_noexception.cpp:0
#2 0x454bb5 in fuzzer::Fuzzer::HandleMalloc(unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:131:3
#3 0x454aca in fuzzer::MallocHook(void const volatile*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:100:6
#4 0x536a37 in __sanitizer::RunMallocHooks(void const*, unsigned long)
/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common.cpp:308:5
#5 0x4a6388 in __asan::Allocator::Allocate(unsigned long, unsigned long,
__sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
/src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:611:5
#6 0x4a6549 in Calloc
/src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:748:17
#7 0x4a6549 in __asan::asan_calloc(unsigned long, unsigned long,
__sanitizer::BufferedStackTrace*)
/src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:969:34
#8 0x525683 in __interceptor_calloc
/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:139:10
#9 0x5f8495 in dwfl_segment_report_module
/src/elfutils/libdwfl/dwfl_segment_report_module.c:907:24
#10 0x566955 in dwfl_core_file_report
/src/elfutils/libdwfl/core-file.c:559:17
#11 0x55eaa0 in LLVMFuzzerTestOneInput /src/fuzz-dwfl-core.c:52:6
#12 0x456df3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) cxa_noexception.cpp:0
#13 0x442642 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned
long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
#14 0x4481bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char
const*, unsigned long)) cxa_noexception.cpp:0
#15 0x4711f2 in main
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#16 0x7f4645ff30b2 in __libc_start_main
/build/glibc-eX1tMB/glibc-2.31/csu/libc-start.c:308:16
#17 0x41f83d in _start
SUMMARY: libFuzzer: out-of-memory
```
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
@ 2021-12-17 9:34 ` mark at klomp dot org
2021-12-17 9:54 ` evvers at ya dot ru
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mark at klomp dot org @ 2021-12-17 9:34 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
Mark Wielaard <mark at klomp dot org> 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 <mark at klomp dot org> ---
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
2021-12-17 9:34 ` [Bug libelf/28685] " mark at klomp dot org
@ 2021-12-17 9:54 ` evvers at ya dot ru
2021-12-19 23:57 ` mark at klomp dot org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-17 9:54 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #2 from Evgeny Vereshchagin <evvers at ya dot ru> ---
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
2021-12-17 9:34 ` [Bug libelf/28685] " mark at klomp dot org
2021-12-17 9:54 ` evvers at ya dot ru
@ 2021-12-19 23:57 ` mark at klomp dot org
2021-12-20 11:34 ` evvers at ya dot ru
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mark at klomp dot org @ 2021-12-19 23:57 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Evgeny Vereshchagin from comment #2)
> 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."
I am not sure I like people explicitly passing in unaligned buffers to
elf_memory (). We'll need to carefully audit that works. It also means lots of
copying data structures around to get a correctly aligned version. Also the
xlate functions work on Elf_Data, I think it is reasonable to assume those
normally come from other libelf functions and that the d_buf pointers are
correctly aligned for the d_type.
For now I just fixed up the code in dwfl_segment_report_module to make sure the
buffers passed to the xlate functions are properly aligned. See the following
proposed patches:
https://sourceware.org/pipermail/elfutils-devel/2021q4/004552.html
https://sourceware.org/pipermail/elfutils-devel/2021q4/004561.html
https://sourceware.org/pipermail/elfutils-devel/2021q4/004562.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (2 preceding siblings ...)
2021-12-19 23:57 ` mark at klomp dot org
@ 2021-12-20 11:34 ` evvers at ya dot ru
2021-12-20 13:19 ` evvers at ya dot ru
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-20 11:34 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #4 from Evgeny Vereshchagin <evvers at ya dot ru> ---
I can confirm that with those three patches applied I can no longer reproduce
the issue. I tested it with both `--enable-honggfuzz` from
https://sourceware.org/pipermail/elfutils-devel/2021q4/004554.html and with
CFlite (which ran the fuzzer for 10 minutes under UBSan)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (3 preceding siblings ...)
2021-12-20 11:34 ` evvers at ya dot ru
@ 2021-12-20 13:19 ` evvers at ya dot ru
2021-12-20 17:27 ` mark at klomp dot org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-20 13:19 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #5 from Evgeny Vereshchagin <evvers at ya dot ru> ---
Created attachment 13867
--> https://sourceware.org/bugzilla/attachment.cgi?id=13867&action=edit
regression
I ran the fuzzer a bit longer and it seems
https://sourceware.org/pipermail/elfutils-devel/2021q4/004562.html introduced a
regression:
```
$ LD_LIBRARY_PATH="./libdw;./libelf" ./src/stack --core
../crash-83c981b28f378121157262f840b36f1ba7089a21
=================================================================
==323325==ERROR: AddressSanitizer: unknown-crash on address 0x7f54aacd7000 at
pc 0x0000004c3efa bp 0x7ffd969da5b0 sp 0x7ffd969d9d60
READ of size 2097120 at 0x7f54aacd7000 thread T0
#0 0x4c3ef9 in __asan_memcpy (/home/vagrant/elfutils/src/stack+0x4c3ef9)
#1 0x7f54ac1b21f4 in memcpy /usr/include/bits/string_fortified.h:29:10
#2 0x7f54ac1b21f4 in dwfl_segment_report_module
/home/vagrant/elfutils/libdwfl/dwfl_segment_report_module.c:466:7
#3 0x7f54ac1c09f8 in dwfl_core_file_report@@ELFUTILS_0.158
/home/vagrant/elfutils/libdwfl/core-file.c:559:17
#4 0x4fe447 in parse_opt /home/vagrant/elfutils/src/stack.c:595:8
#5 0x7f54abbcb471 in argp_parse (/lib64/libc.so.6+0x11e471)
#6 0x4fd99d in main /home/vagrant/elfutils/src/stack.c:695:3
#7 0x7f54abada55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#8 0x7f54abada60b in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x2d60b)
#9 0x41d6c4 in _start (/home/vagrant/elfutils/src/stack+0x41d6c4)
Address 0x7f54aacd7000 is a wild pointer inside of access range of size
0x0000001fffe0.
SUMMARY: AddressSanitizer: unknown-crash
(/home/vagrant/elfutils/src/stack+0x4c3ef9) in __asan_memcpy
Shadow bytes around the buggy address:
0x0feb15592db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0feb15592dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0feb15592dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0feb15592de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0feb15592df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0feb15592e00:[fe]fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
0x0feb15592e10: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
0x0feb15592e20: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
0x0feb15592e30: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
0x0feb15592e40: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
0x0feb15592e50: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==323325==ABORTING
```
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (4 preceding siblings ...)
2021-12-20 13:19 ` evvers at ya dot ru
@ 2021-12-20 17:27 ` mark at klomp dot org
2021-12-20 19:01 ` evvers at ya dot ru
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mark at klomp dot org @ 2021-12-20 17:27 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
I cannot replicate this with either an amd64 build or a i686 build.
I might have some more patches applied locally because the line
dwfl_segment_report_module.c:466 doesn't contain a memcpy call for me.
All local patches I have applied (all sent to the elfutils-devel list) can be
found here: https://code.wildebeest.org/git/user/mjw/elfutils/log/?h=fuzz
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (5 preceding siblings ...)
2021-12-20 17:27 ` mark at klomp dot org
@ 2021-12-20 19:01 ` evvers at ya dot ru
2021-12-20 22:34 ` evvers at ya dot ru
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-20 19:01 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #7 from Evgeny Vereshchagin <evvers at ya dot ru> ---
Created attachment 13869
--> https://sourceware.org/bugzilla/attachment.cgi?id=13869&action=edit
archive with a report and a file triggering a memory leak
Thanks! That branch helped me a lot. I rebased it on top of my "fuzz" branch
and pushed it to trigger the tests. CFLite reported a memory leak:
```
$ DEBUGINFOD_URLS= LD_LIBRARY_PATH="./libdw;./libelf" valgrind
--leak-check=full ./src/stack --core
./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1
==379530== Memcheck, a memory error detector
==379530== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==379530== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==379530== Command: ./src/stack --core
./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1
==379530==
PID 1147239 - core
TID 1147239:
#0 0x000055dea11b3135
./src/stack: dwfl_thread_getframes tid 1147239 at 0x55dea11b3135 in <unknown>:
invalid operation
==379530==
==379530== HEAP SUMMARY:
==379530== in use at exit: 37,280 bytes in 97 blocks
==379530== total heap usage: 4,597 allocs, 4,500 frees, 302,708 bytes
allocated
==379530==
==379530== 20 bytes in 1 blocks are definitely lost in loss record 1 of 8
==379530== at 0x484186F: malloc (vg_replace_malloc.c:381)
==379530== by 0x48C4E15: dwfl_segment_report_module
(dwfl_segment_report_module.c:632)
==379530== by 0x48C8F3E: dwfl_core_file_report@@ELFUTILS_0.158
(core-file.c:559)
==379530== by 0x402EC6: parse_opt (stack.c:595)
==379530== by 0x4C4E471: argp_parse (in /usr/lib64/libc.so.6)
==379530== by 0x4024EA: main (stack.c:695)
==379530==
==379530== LEAK SUMMARY:
==379530== definitely lost: 20 bytes in 1 blocks
==379530== indirectly lost: 0 bytes in 0 blocks
==379530== possibly lost: 0 bytes in 0 blocks
==379530== still reachable: 37,260 bytes in 96 blocks
==379530== suppressed: 0 bytes in 0 blocks
==379530== Reachable blocks (those to which a pointer was found) are not shown.
==379530== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==379530==
==379530== For lists of detected and suppressed errors, rerun with: -s
==379530== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
```
I haven't tested it with the files that triggered the regression I mentioned at
https://sourceware.org/bugzilla/show_bug.cgi?id=28685#c5 . I'll put those files
to the "seed" corpus and report back.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (6 preceding siblings ...)
2021-12-20 19:01 ` evvers at ya dot ru
@ 2021-12-20 22:34 ` evvers at ya dot ru
2021-12-21 0:01 ` mark at klomp dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-20 22:34 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #8 from Evgeny Vereshchagin <evvers at ya dot ru> ---
I can't reproduce that "unknown-crash on address 0x7f54aacd7000" anymore.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (7 preceding siblings ...)
2021-12-20 22:34 ` evvers at ya dot ru
@ 2021-12-21 0:01 ` mark at klomp dot org
2021-12-21 1:51 ` evvers at ya dot ru
2021-12-21 11:13 ` mark at klomp dot org
10 siblings, 0 replies; 12+ messages in thread
From: mark at klomp dot org @ 2021-12-21 0:01 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Evgeny Vereshchagin from comment #7)
> Created attachment 13869 [details]
> archive with a report and a file triggering a memory leak
>
> Thanks! That branch helped me a lot. I rebased it on top of my "fuzz" branch
> and pushed it to trigger the tests. CFLite reported a memory leak:
> ```
> $ DEBUGINFOD_URLS= LD_LIBRARY_PATH="./libdw;./libelf" valgrind
> --leak-check=full ./src/stack --core
> ./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1
> ==379530== Memcheck, a memory error detector
> ==379530== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==379530== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
> ==379530== Command: ./src/stack --core
> ./MEMLEAK/address/leak-8cd1af3e2ba6f343794fbee7232b1531695d2ab1
> ==379530==
> PID 1147239 - core
> TID 1147239:
> #0 0x000055dea11b3135
> ./src/stack: dwfl_thread_getframes tid 1147239 at 0x55dea11b3135 in
> <unknown>: invalid operation
> ==379530==
> ==379530== HEAP SUMMARY:
> ==379530== in use at exit: 37,280 bytes in 97 blocks
> ==379530== total heap usage: 4,597 allocs, 4,500 frees, 302,708 bytes
> allocated
> ==379530==
> ==379530== 20 bytes in 1 blocks are definitely lost in loss record 1 of 8
> ==379530== at 0x484186F: malloc (vg_replace_malloc.c:381)
> ==379530== by 0x48C4E15: dwfl_segment_report_module
> (dwfl_segment_report_module.c:632)
> ==379530== by 0x48C8F3E: dwfl_core_file_report@@ELFUTILS_0.158
> (core-file.c:559)
> ==379530== by 0x402EC6: parse_opt (stack.c:595)
> ==379530== by 0x4C4E471: argp_parse (in /usr/lib64/libc.so.6)
> ==379530== by 0x4024EA: main (stack.c:695)
Aha, we have more error paths now and not all cleaned up the buildid memory.
Proposed cleanup patch:
https://sourceware.org/pipermail/elfutils-devel/2021q4/004582.html
https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=fuzz
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (8 preceding siblings ...)
2021-12-21 0:01 ` mark at klomp dot org
@ 2021-12-21 1:51 ` evvers at ya dot ru
2021-12-21 11:13 ` mark at klomp dot org
10 siblings, 0 replies; 12+ messages in thread
From: evvers at ya dot ru @ 2021-12-21 1:51 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
--- Comment #10 from Evgeny Vereshchagin <evvers at ya dot ru> ---
Looks like the memory leak is gone. Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libelf/28685] UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr'
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
` (9 preceding siblings ...)
2021-12-21 1:51 ` evvers at ya dot ru
@ 2021-12-21 11:13 ` mark at klomp dot org
10 siblings, 0 replies; 12+ messages in thread
From: mark at klomp dot org @ 2021-12-21 11:13 UTC (permalink / raw)
To: elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=28685
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #11 from Mark Wielaard <mark at klomp dot org> ---
Thanks for testing, I pushed all 13 commits from my fuzz branch.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-12-21 11:13 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-11 21:32 [Bug libelf/28685] New: UBSan: member access within misaligned address 0x7ff316818032 for type 'struct Elf32_Phdr' evvers at ya dot ru
2021-12-17 9:34 ` [Bug libelf/28685] " mark at klomp dot org
2021-12-17 9:54 ` evvers at ya dot ru
2021-12-19 23:57 ` mark at klomp dot org
2021-12-20 11:34 ` evvers at ya dot ru
2021-12-20 13:19 ` evvers at ya dot ru
2021-12-20 17:27 ` mark at klomp dot org
2021-12-20 19:01 ` evvers at ya dot ru
2021-12-20 22:34 ` evvers at ya dot ru
2021-12-21 0:01 ` mark at klomp dot org
2021-12-21 1:51 ` evvers at ya dot ru
2021-12-21 11:13 ` mark at klomp dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).