Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/443547551
Changed
ev...@gmail.com added comment #2:
It can be reproduced by building elfutils with ASan, downloading the
testcase from https://oss-fuzz.com/
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/443547551
Reference Info: 443547551 elfutils:fuzz-libdwfl: Null-dereference READ in
process_file
component: Public Trackers > 1362134 > OSS Fuzz
status: Ne
Within create_dwfl, if dwfl_begin is successful but dwfl_report_offline
fails, the dwfl * pointer being reported is reset to NULL without calling
dwfl_end, causing a memory leak.
Update create_dwfl to call dwfl_end in this case, preventing the leak.
Signed-off-by: Aaron Merey
---
src/readelf.c
Before creating an elf descriptor for an archive member, dup_elf
verifies that the size of an archive is large enough to contain the
member. This check uses the member's offset relative to the map_address
of the top-level archive containing the member.
This check can incorrectly fail when an arch
Hi Evgeny,
On Sun, Sep 7, 2025 at 11:31 AM Evgeny wrote:
> On Sun, 7 Sept 2025 at 00:58, Mark Wielaard wrote:
> > > I can confirm that this patch (combined with the patch where
> > > libdw_open_elf
> > > is fixed) addresses several issues reported by OSS-Fuzz. As far as I can
> > > see
> > > s
If elf_getarhdr is called on a descriptor that refers to an archive that
is itself a member of an outer archive, it may return the Elf_Arhdr of
the current member of the inner archive instead of Elf_Arhdr of the inner
archive itself.
This also causes a memory leak: elf_end only attempts to free
El
Hi Mark,
On Sun, 7 Sept 2025 at 00:58, Mark Wielaard wrote:
> > I can confirm that this patch (combined with the patch where libdw_open_elf
> > is fixed) addresses several issues reported by OSS-Fuzz. As far as I can see
> > some issues are still reproducible but I'd wait for OSS-Fuzz to
> > aut
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/440209723
Changed
ev...@gmail.com added comment #2:
Looks like it's still reproducible. It can be reproduced by running
`readelf -a` with the testcase downl
If libdw_open_elf detects an invalid ELF file, it may attempt to
temporarily treat it as an ELF archive in order to check if there's
a valid ELF file following a header.
When doing this, the elf descriptor for the invalid file is given
the dummy state.ar.elf_ar_hdr.ar_name "libdwfl is faking you o
Hi Aaron,
On Mon, Aug 04, 2025 at 11:24:41PM -0400, Aaron Merey wrote:
> Signed-off-by: Aaron Merey
> ---
> v2: Some rewording. Also remove comment about elf_rand affecting
> subsequent calls to elf_next. I will post a patch that prevents this
> behavior.
Thanks, that patch is now in. commit cc
Hi Mark
On Sat, 6 Sept 2025 at 13:50, Mark Wielaard wrote:
> This, plus Aaron's fix for libdw_open_elf, should resolve the ossfuzz
> issues.
I can confirm that this patch (combined with the patch where libdw_open_elf
is fixed) addresses several issues reported by OSS-Fuzz. As far as I can see
so
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/442253757
Changed
ev...@gmail.com added comment #4:
In the meantime I reproduced it locally by installing clang and running the
following commands:
```
git
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/442253757
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/443254909
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/442161254
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/440144412
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/441055980
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
Replying to this email means your email address will be shared with the
team that works on this product.
https://issues.oss-fuzz.com/issues/440209728
Changed
status: New → Verified
assignee: → cl...@appspot.gserviceaccount.com
verifier: → cl...@appspot.gserviceaccount.com
87...@developer.gs
18 matches
Mail list logo
