The afl fuzzer found that we would overflow the needed bytes when
calculating how many index entries would fit in the .debug_loclists
and .debug_rnglists tables. To fix this just calculate the max number
of entries. If the offset entry count is larger than that, do emit
an error, but print up to ma
If the target of a DW_OP_GNU_parameter_ref isn't a DW_TAG_formal_parameter
that is bad data (which varlocs should error on). But it isn't an internal
consistency check (for which varlocs should assert).
Signed-off-by: Mark Wielaard
---
tests/ChangeLog | 5 +
tests/varlocs.c | 3 ++-
2 files
When the given Dwarf_Die was invalid we might crash and when the offset
was totally bogus we might succeed with a random abbrev.
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog | 4
libdw/dwarf_getabbrev.c | 20 +---
tests/ChangeLog | 5 +
tests/
The other dwarf unit/cu iterators handle a NULL Dwarf handle as an
existing error and return NULL. Don't crash.
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog | 5 +
libdw/dwarf_get_units.c | 4
2 files changed, 9 insertions(+)
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
i
On Thu, 2018-06-07 at 00:01 +0200, Mark Wielaard wrote:
> Found by afl fuzzer on varlocs test. varlocs sanity checks that the
> given offset in the opcode corresponds to the cuoffset of the returned
> DIE. In case the opcode offset was bogus this might fail because we
> might wrap around and return
On Wed, 2018-06-06 at 23:43 +0200, Mark Wielaard wrote:
> When using the varlocs test with a fuzzer using assert for internal
> sanity checks is great to find issues. But when encountering bad data
> using an assert is wrong. Just use error to show we handle the data
> correctly (by reporting it is
The afl fuzzer running against the varlocs test detected we didn't report
the value block of a DW_OP_implicit_value consistently when the DWARF was
bad. Although this doesn't cause a crash it might result in consumers
using dwarf_getlocation_implicit_value seeing an inconsistent block length
value.
It is only a consistency issue if we actually have an cfi_debug and the
cfi_debug_bias is not zero (because they come from the same file as the
other debug data).
Signed-off-by: Mark Wielaard
---
tests/ChangeLog | 5 +
tests/varlocs.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
The afl fuzzer found that the way we handle "too many" directories or files
in the (DWARF5 style) line table badly. In the case of eu-readelf we would
print an endless stream of "bad directory" or "bad file". Just stop printing
when the end of data is reached. In the case of dwarf_getsrclines we wo
On Tue, 2018-06-05 at 23:23 +0200, Mark Wielaard wrote:
> We would print a "fake" .debug_addr header, but didn't always setup the
> unit_length (in case there was a mix of GNU DebugFission and DWARF5 tables).
> Make sure to always set the unit_length (we do always calculate the next
> unit offset a
On Tue, 2018-06-05 at 23:36 +0200, Mark Wielaard wrote:
> It is highly unlikely dwarf_formudata fails because we setup the attribute
> ourselves, but better to explicitly mark diridx as bad if it does.
Pushed to master.
On Tue, 2018-06-05 at 22:44 +0200, Mark Wielaard wrote:
> In the unlikely case that __libdw_findcu fails to find the associated
> CU we would leak one arange because it wasn't linked into the arangelist
> list yet. Make sure to free it immediately.
Pushed to master.
On Tue, 2018-06-05 at 23:06 +0200, Mark Wielaard wrote:
> When printing the GNU DebugFission location entries we want to print the
> start idx as begin, if we cannot find the address index.
> A copy/paste error set up end instead of begin in that case causing us
> to print garbage (in the unlikely
On Tue, 2018-06-05 at 21:55 +0200, Mark Wielaard wrote:
> In both handle_sysv_hash and handle_sysv_hash64 we check the has chain
> isn't too long. If it is we would report an error and leak the lengths
> array. Just clean up the array even in the error case.
Pushed to master.
On Tue, 2018-06-05 at 22:33 +0200, Mark Wielaard wrote:
> If there were more than 256 directories in the table and there was
> illegal DWARF before we read them all, then we might not free the
> dirarray (or the wrong one). Fix by defining the dirarray early
> (before the first data sanity check) a
On Tue, 2018-06-05 at 21:06 +0200, Mark Wielaard wrote:
> The vendor array should have room for all vendor opcode, including
> DW_MACRO_hi_user if used.
Pushed to master.
On Tue, 2018-06-05 at 21:33 +0200, Mark Wielaard wrote:
> The MAX_BUILD_ID_BYTES is fairly large (64), while normally build-ids
> are only 20 bytes long. But if we would encounter a jumbo build-id we
> should have enough room to construct the full build-id path.
>
> We used to substract 2 bytes fr
On Tue, 2018-06-05 at 00:04 +0200, Mark Wielaard wrote:
> __libdwfl_addrsym is only used in the dwfl_module_addrsym.c source.
> There is no need to mark this as a (shared) internal function.
Pushed to master.
When constructing a "fake" Dwarf_Attribute for DW_OP_GNU_const_index,
DW_OP_constx, DW_OP_GNU_addr_index or DW_OP_addrx, we would create a
fake attribute pointing to the actual data in the .debug_addr section.
We would even do that if there was no .debug_addr section assuming
dwarf_formaddr or dwa
19 matches
Mail list logo
