When trying to read (corrupt) phdrs from a core file we only want
to read and convert the bytes we could read. Also make sure we don't
try to allocate too big buffers.
https://sourceware.org/bugzilla/show_bug.cgi?id=28666
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 6 ++
libdwfl/
https://sourceware.org/bugzilla/show_bug.cgi?id=28666
--- Comment #3 from Mark Wielaard ---
Proposed patch:
https://patchwork.sourceware.org/project/elfutils/patch/20211208133606.7658-1-m...@klomp.org/
--
You are receiving this mail because:
You are on the CC list for the bug.
Hi Frank,
On Wed, 2021-12-01 at 10:23 -0500, Frank Ch. Eigler wrote:
> > Although unlikely the MHD_add_response_header can fail for
> > various reasons. If it fails something odd is going on.
> > So check we can actually add a response header and log an
> > error if we cannot.
>
> TBH I wouldn't
Although unlikely the MHD_add_response_header can fail for
various reasons. If it fails something odd is going on.
So check we can actually add a response header and log an
error if we cannot.
Signed-off-by: Mark Wielaard
---
debuginfod/ChangeLog | 12
debuginfod/debuginfod.cxx |
Hi Evgeny,
On Sun, 2021-12-05 at 19:52 +0300, Evgeny Vereshchagin wrote:
> > See how I used it to workaround isssues with the
> > gcc address sanitizer. You can use it likewise to work around
> > issues
> > with clang. e.g. the configure check should detect the issue with
> > --no-undefined and co
Hi Alexander,
On Sun, 2021-12-05 at 21:45 +0100, Alexander Kanavin wrote:
> I'm not sure; the point of this patch is simply to ensure debuginfod builds
> everywhere without errors. Making the types consistent is perhaps better
> done as a followup?
I think the issue of the code not compiling in s
Hi -
> Although unlikely the MHD_add_response_header can fail for
> various reasons. If it fails something odd is going on.
> So check we can actually add a response header and log an
> error if we cannot.
Sure, if you insist. :-)
except:
> - *size = os.size();
> - MHD_add_response_header (r
Hi Frank,
On Wed, 2021-12-08 at 10:32 -0500, Frank Ch. Eigler wrote:
> except:
>
> > - *size = os.size();
> > - MHD_add_response_header (r, "Content-Type", "text/plain");
> > + if (r != NULL)
> > +{
> > + *size = os.size();
> > + add_mhd_response_header (r, "Content-Type", "text/
Hi -
> > Why move the *size assignment in there?
>
> Because both statements are unnecessary if r == NULL (aka the response
> couldn't even be created). [...]
> But it is also harmless to do, so if you want I can move it outside the
> if statement.
OK, whichever, doesn't much matter then.
- FChE
Hi -
Committing as obvious.
Author: Frank Ch. Eigler
Date: Wed Dec 8 10:20:58 2021 -0500
debuginfod: correct concurrency bug in fdcache metrics
The intern() function called set_metrics() outside a necessary lock
being held. helgrind identified this race condition. No QA imp
The ELF might not be fully mapped into memory (which probably means
the phdrs are bogus). Don't try to read beyond what we have in memory
already.
Reported-by: Evgeny Vereshchagin
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog| 5 +
libdwfl/dwfl_segment_report_module
While iterating the notes we could overflow the len variable if the
note name or description was too big. Fix this by adding an (unsigned)
overflow check.
https://sourceware.org/bugzilla/show_bug.cgi?id=28654
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog| 5 +
libdw
https://sourceware.org/bugzilla/show_bug.cgi?id=28654
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2021-12-08
Status|UNCONFI
The Buildbot has detected a new failure on builder elfutils-centos-x86_64 while
building elfutils.
Full details are available at:
https://builder.wildebeest.org/buildbot/#builders/1/builds/868
Buildbot URL: https://builder.wildebeest.org/buildbot/
Worker for this Build: centos-x86_64
Build
https://sourceware.org/bugzilla/show_bug.cgi?id=28666
--- Comment #4 from Evgeny Vereshchagin ---
With that patch applied I can confirm that the issue is gone.Just to make sure
also run the unit tests on aarch64, i386, ppc64le and x86_64 and they all
passed there. Thanks!
--
You are receiving t
https://sourceware.org/bugzilla/show_bug.cgi?id=28654
--- Comment #2 from Evgeny Vereshchagin ---
I applied the patch on top of the master branch with the other two patches
related to libwfl applied and ran `src/stack` under Valgrind. I also ran the
unit tests on four different architectures just
Hi Mark,
> But that doesn't really work if you use clang.
It kind of does because almost everybody who builds their projects with clang
sanitizers
turns off `z,defs` and `--no-undefined`. I agree it looks weird (and it's
probably weird) but
it's just how it has been done for I don't know how ma
Without the program header entry size we cannot search through the
phdrs.
https://sourceware.org/bugzilla/show_bug.cgi?id=28657
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 4
libdwfl/link_map.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libdwfl/ChangeLo
https://sourceware.org/bugzilla/show_bug.cgi?id=28657
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
Ever confir
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=28660
--- Comment #2 from Evgeny Vereshchagin ---
As far as I can see both issues are gone with that patch applied. Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28666
--- Comment #5 from Evgeny Vereshchagin ---
I was able to trigger the same issue with a different file by running the fuzz
target a bit longer. I'll double check and attach the file
--
You are receiving this mail because:
You are on the CC l
https://sourceware.org/bugzilla/show_bug.cgi?id=28666
--- Comment #6 from Evgeny Vereshchagin ---
My bad. The backtrace is different there:
```
2021-12-08T20:14:08.7167911Z ==21==ERROR: AddressSanitizer:
heap-buffer-overflow on address 0x7f4f1d328000 at pc 0x00524c9f bp
0x7fff9271bc40 sp 0x7f
When calulating the possible section header table end us the actual size
of the section headers (sizeof (Elf32_Shdr) or sizeof (Elf64_Shdr)),
not the ELF header e_shentsize value, which can be corrupted. This
prevents a posssible overflow, but we check the shdrs_end is sane
later anyway.
https://s
https://sourceware.org/bugzilla/show_bug.cgi?id=28659
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
On Wed, Dec 08, 2021 at 05:20:29PM +, build...@builder.wildebeest.org wrote:
> The Buildbot has detected a new failure on builder elfutils-centos-x86_64
> while building elfutils.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/1/builds/868
>
> Buildbo
On Wed, Dec 08, 2021 at 10:46:29AM -0500, Frank Ch. Eigler via Elfutils-devel
wrote:
> Hi -
>
> > > Why move the *size assignment in there?
> >
> > Because both statements are unnecessary if r == NULL (aka the response
> > couldn't even be created). [...]
> > But it is also harmless to do, so if
https://sourceware.org/bugzilla/show_bug.cgi?id=28659
--- Comment #2 from Evgeny Vereshchagin ---
> Note that the overflow is actually harmless
It is but since the fuzz target ran into it almost as soon as it started it
prevented the fuzz target from discovering new issues that can be less harml
dwfl_segment_report_module can be called with the same module
name, start and end address twice (probably because of a corrupt
core file). In that case don't override the main.elf handle if
it already exists.
https://sourceware.org/bugzilla/show_bug.cgi?id=28655
Signed-off-by: Mark Wielaard
---
https://sourceware.org/bugzilla/show_bug.cgi?id=28655
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
Sta
On Sat, Dec 04, 2021 at 10:15:04PM +0100, Mark Wielaard wrote:
> In function ‘strncpy’,
> inlined from ‘print_ehdr’ at readelf.c:1175:4:
> error: ‘__builtin_strncpy’ specified bound 512 equals destination size
>[-Werror=stringop-truncation]
>
> strncpy doesn't terminate the copied stri
On Sat, Dec 04, 2021 at 10:27:29PM +0100, Mark Wielaard wrote:
> In function ‘printf’,
> inlined from ‘handle_attr’ at varlocs.c:932:3:
> error: ‘%s’ directive argument is null [-Werror=format-overflow=]
>
> The warning is technically correct. A %s argument should not be
> NULL. Although in pr
On Sat, Dec 04, 2021 at 10:33:35PM +0100, Mark Wielaard wrote:
> gcc address sanitizer detected a dangling debuginfod_client handler
> when debuginfod exits. Make sure to groom the debuginfod client pool
> before exit after all threads are done.
Pushed,
Mark
Hi,
On Sun, Dec 05, 2021 at 02:39:25AM +0100, Mark Wielaard wrote:
> --enable-sanitize-address makes sure that all code is compiled with
> -fsanitizer=address and all tests run against libasan.
>
> It can be combined with --enable-sanitize-undefined, but not with
> --enable-valgrind.
>
> In main
https://sourceware.org/bugzilla/show_bug.cgi?id=28655
--- Comment #2 from Evgeny Vereshchagin ---
I can't seem to reproduce that memory leak anymore. Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
Hi -
> [...]
> We seem to not expect these intervals to be much bigger than a week,
> so an int should always be big enough (even when stretched up to a
> whole year).
Yes, ints are fine for these humane-number-of-seconds kinds of values
in the cache configuration. There's no need for maximum le
Hi -
While I think this patch itself is fine, and works around the
libmicrohttpd bug that motivated it, I don't know how to test it
seriously in the testsuite. (We can certainly try few -C options for
parsing & operability.) The error edge cases only appear to occur
under very high load and task
37 matches
Mail list logo
