<?xml version="1.0" encoding="us-ascii"?>
<dwarfbug>
<dwbug>
<dwid>DW202407-012</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70763</fuzzer>
<datereported>2024-07-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> InfiniteRecursion reading CUs leads to crash
</vulnerability>
<description> The code added in git fix id
6b40a0ed378826273080a7b11e7274c2b61d018b
two days ago involved adding code setting up
compilation unit data and in find_cu_die_base_fields()
we called dwarf_global_formref() whereas we must
call _dwarf_internal_global_formref_b() to avoid
an infinite recursion.
A crash was only possible when reading corrupt DWARF.
</description>
<datefixed>2024-07-28</datefixed>
<references> regressiontests/ossfuzz70763/fuzz_macro_dwarf5-5161075908083712
</references>
<gitfixid>1b79d618bf5aab2bda9be495c531b13e94ae056a</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-011</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70753</fuzzer>
<datereported>2024-07-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> InfiniteRecursion reading CUs leads to crash
</vulnerability>
<description> The code added in git fix id
6b40a0ed378826273080a7b11e7274c2b61d018b
two days ago involved adding code setting up
compilation unit data and in find_cu_die_base_fields()
we called dwarf_global_formref() whereas we must
call _dwarf_internal_global_formref_b() to avoid
an infinite recursion.
A crash was only possible when reading corrupt DWARF.
</description>
<datefixed>2024-07-28</datefixed>
<references> regressiontests/ossfuzz70753/fuzz_die_cu_offset-6598270743281664
</references>
<gitfixid>1b79d618bf5aab2bda9be495c531b13e94ae056a</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-010</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70721</fuzzer>
<datereported>2024-07-27</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Use After Free
</vulnerability>
<description> Libdwarf was referencing freed space
attempting to free up a compilation-unit DIE
in the process of creating a context for a
compilation-unit DIE, given a particular
corruption of the DWARF data being read.
This bug has been present for several years.
</description>
<datefixed>2024-07-27</datefixed>
<references> regressiontests/ossfuzz70721/fuzz_macro_dwarf5-4907954017468416
</references>
<gitfixid>6fa96f95e043bac9b98ca6f7a9a542dae8f46cd</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-009</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70287</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70287/
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-008</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70282</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70282/
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-007</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70278</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70278/
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-006</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70277</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70277/
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-005</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70266</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70266/fuzz_findfuncbypc-6093996460408832
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-004</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70263</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70263/fuzz_die_cu-4960441042796544
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-003</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70256</fuzzer>
<datereported>2024-07-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70256/fuzz_rng-483822291655065
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70246</fuzzer>
<datereported>2024-07-09</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Huge malloc request could crash caller
</vulnerability>
<description> Libdwarf was not checking a field in
a .debug_rnglists header for sanity before doing
a malloc based on the field value.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-10</datefixed>
<references> regressiontests/ossfuzz70246/fuzz_macro_dwarf5-5128935898152960
</references>
<gitfixid>d7c4efdcc7952b38a237a36ccedf364018e0fb1c</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202407-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 70244</fuzzer>
<datereported>2024-07-09</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory leaks reading rnglists
</vulnerability>
<description> Libdwarf was failing to free()
some allocations in reading .debug_rnglists.
This bug has been present for a week or so.
</description>
<datefixed>2024-07-09</datefixed>
<references> regressiontests/ossfuzz70244/fuzz_die_cu_attrs_loclist-4958134427254784
</references>
<gitfixid>906a4428a5d92e17948da4249cfccbe8f5ae8005</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW202406-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 69641</fuzzer>
<datereported>2024-06-14</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory Leak reading .debug_loclists
</vulnerability>
<description> During startup (reading
initial fields from .debug_loclists)
libdwarf was allocating
an array of integers but in the normal
case was failing to free the array.
This bug in DWARF5 handling
has been in the code for a week or so.
See also DW202406-001.
</description>
<datefixed>2024-06-15</datefixed>
<references> regressiontests/ossfuzz69641/fuzz_die_cu_attrs_loclist-6271271030030336
</references>
<gitfixid>32d832900ebe2e61ec07e82625a561415be05424</gitfixid>
<tarrelease>libdwarf-0.10.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202406-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 69639</fuzzer>
<datereported>2024-06-14</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory Leak reading .debug_loclists
</vulnerability>
<description> During startup (reading
initial fields from .debug_loclists)
libdwarf was allocating
an array of integers but in the normal
case was failing to free the array.
This bug in DWARF5 handling
has been in the code for a week or so.
See also DW202406-002.
</description>
<datefixed>2024-06-15</datefixed>
<references> regressiontests/ossfuzz69639/fuzz_die_cu_offset-6001910176350208
</references>
<gitfixid>32d832900ebe2e61ec07e82625a561415be05424</gitfixid>
<tarrelease>libdwarf-0.10.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202403-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 67490</fuzzer>
<datereported>2024-03-18</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Reads past end of line table
</vulnerability>
<description> A carefully corrupted line table
header can cause libdwarf to read outside of its
allowed areas in a .debug_line section reading
the file names part of the header.
The failure to check for end-of-section before reading
past end-of-section at the very last byte in section
(at a very few specific
points in the line table reader code where a
valid line table header would not require a test)
has been present for many years.
</description>
<datefixed>2024-02-19</datefixed>
<references> regressiontests/ossfuzz67490/fuzz_srcfiles-5195296927711232
</references>
<gitfixid>2930f3121ee6b07da405103934c329bbeca0382f</gitfixid>
<tarrelease>libdwarf-0.9.2.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202402-003</dwid>
<cve></cve>
<fuzzer>hongg</fuzzer>
<datereported>2024-02-18</datereported>
<reportedby>ifygecko</reportedby>
<product>libdwarf</product>
<vulnerability> crashes randomly reading fuzzed locllist
</vulnerability>
<description> A carefully corrupted loclists entry
can cause libdwarf to read outside of its
allowed areas in dwarf_loclists.c due to lack of a
sanity check.
A segmentation error and libdwarf crash is likely.
Similar code in dwarf_rnglists.c and that now
has the additional checks.
The bugs have been present in both since the code was created
in June 2020.
</description>
<datefixed>2024-02-18</datefixed>
<references> regressiontests/hongg2024-02-18/SIGSEGV-m.fuzz
</references>
<gitfixid>5cfbd87dff4fc3c3b595bb92ed886934945b372c</gitfixid>
<tarrelease>libdwarf-0.9.2.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202402-002</dwid>
<cve>CVE-2024-2002</cve>
<fuzzer>hongg</fuzzer>
<datereported>2024-02-16</datereported>
<reportedby>ifygecko</reportedby>
<product>libdwarf</product>
<vulnerability> crashes randomly on fuzzed object
</vulnerability>
<description> In a multiply-corrupted DWARF object
libdwarf may try to dealloc(free) an allocation twice.
Results are unpredictable and various.
This has been a possibility since we added code
to prevent leaks when generating 'unattached'
Dwarf_Error records (where there is no
Dwarf_Debug available at the point of error).
The problem was introduced in libdwarf-0.1.0
in 2021.
</description>
<datefixed>2024-02-17</datefixed>
<references> regressiontests/hongg2024-02-16/SIGABRT-a.fuzz
SIGABRT-b.fuzz SIGABRT-c.fuzz SIGSEGV-d.fuzz
SIGSEGV-e.fuzz SIGSEGV-f.fuzz SIGSEGV-g.fuzz
SIGSEGV-h.fuzz SIGSEGV-i.fuzz SIGSEGV-k.fuzz
</references>
<gitfixid>404e6b1b14f60c81388d50b4239f81d461b3c3ad</gitfixid>
<tarrelease>libdwarf-0.9.2.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202402-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 66646</fuzzer>
<datereported>2024-02-12</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Reference memory outside of section.
</vulnerability>
<description> The data pointer for DW_FORM_ref1
was not being validated as pointing into the section before
being dereferenced. Here reading a corrupted
DWARF section. A library crash is likely.
This test failure happened to be on a
DW_AT_abstract_origin attribute,
but the problem applies in many other situations.
Nearly the other forms had checks.
This check has been missing for many years.
Similarly the requisite check was missing from
DW_FORM_block1 for many years and that too
was fixed so all the FORMs have checks now.
</description>
<datefixed>2024-02-13</datefixed>
<references> regressiontests/ossfuzz66646/fuzz_findfuncbypc-5178544143532032
</references>
<gitfixid>f21e2f7687f3dca183026a1fb72ca1f0dcf8befa</gitfixid>
<tarrelease>libdwarf-0.9.2.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202311-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 64496</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference from dwarf_gnu_debuglink()
</vulnerability>
<description> If the Dwarf_Debug was opened with
dwarf_init_object_b() there is no pathname known to libdwarf
and the library was dereferencing a null pointer as a result.
With the library bug fixed
the fuzz/fuzz_debuglink.c test case was violating the
rules of use of the function resulting in memory
leakage. The documentation has been improved on this
function.
</description>
<datefixed>2023-11-25</datefixed>
<references> regressiontests/ossfuzz64496/fuzz_debuglink-615437663823462
</references>
<gitfixid>d76cce559b898f7059ce5ffd82f3cfd58cb392fe</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202311-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56452</fuzzer>
<datereported>2023-11-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference
</vulnerability>
<description> Passing a null Dwarf_Debug to
dwarf_add_debuglink_global_path() lead to library crash.
The code was not checking for a valid Dwarf_Debug Argument.
The bug was present when the function was created in 2021
Moreover, oss fuzz originally noted the bug
on 02 March 2023 but
I can find no trace of a notification of the bug arriving
before 24 November 2023.
Fixing this sort of thing for all functions, here is
the last commit id...
ef77596af000719c04bd3e40b97139247ff3efb4
</description>
<datefixed>2023-11-25</datefixed>
<references> regressiontests/ossfuzz56452/fuzz_debuglink-cs4231a-5927365017731072
</references>
<gitfixid>1f6988307748f427566e3266695bb72d5384bf3d</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202310-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 63024</fuzzer>
<datereported>2023-10-06</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> A copy-paste error lead to
a heap buffer overflow. Named the wrong struct
in calling calloc().
The function with the bug was added seven days ago.
</description>
<datefixed>2023-10-07</datefixed>
<references> regressiontests/ossfuzz63024/fuzz_init_path-5486726493372416
</references>
<gitfixid>3a658bd1dd7437948cecbf82bb9b24f5f6122a7d</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202310-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 62943</fuzzer>
<datereported>2023-10-02</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> The heap buffer overflow was due
to a failure to do initial sanity checks on a
universal object. The object involved was
not large enough to have a complete universal
header.
This bug was in the public repository
for three days (in all-new code, for Apple
Universal Binary objects).
</description>
<datefixed>2023-10-03</datefixed>
<references> regressiontests/ossfuzz62943/fuzz_init_path-5486726493372416
</references>
<gitfixid>aea77dad8745d9aad5275c3226e4e3156effa71f</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202309-004</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 62842</fuzzer>
<datereported>2023-09-30</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> The heap buffer overflow in
_dwarf_memcpy_swap_bytes was due a failure to check
for a valid size field (a fuzzed value) in a count
of array elements..
Now we check for a sensible count.
This bug was in the public repository
for two days (in all-new code, for Apple
Universal Binary objects).
</description>
<datefixed>2023-10-01</datefixed>
<references> regressiontests/ossfuzz62842/fuzz_findfuncbypc-4964619766333440.fuzz
</references>
<gitfixid>f7c7e84e5a77915bb6570215887118d8e7759122</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202309-003</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 62834</fuzzer>
<datereported>2023-09-30</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory leak in _dwarf_macho_setup()
</vulnerability>
<description> The September 29 addition of Mach-O
universal binary support
resulted in memory leaks due to revising memory alloc/free
incompletely when fuzzed object files were encountered..
This bug was in the public repository
for two days (in all-new code, for Apple
Universal Binary objects).
</description>
<datefixed>2023-10-01</datefixed>
<references> regressiontests/ossfuzz62834/fuzz_init_path-4573857635500032
</references>
<gitfixid>f7c7e84e5a77915bb6570215887118d8e7759122</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202309-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 62833</fuzzer>
<datereported>2023-09-30</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory leak in _dwarf_macho_setup()
</vulnerability>
<description> The September 29 addition of Mach-O
universal binary support
resulted in memory leaks due to revising memory alloc/free
incompletely when fuzzed object files were encountered..
This bug was in the public repository
for two days (in all-new code, for Apple
Universal Binary objects).
</description>
<datefixed>2023-10-01</datefixed>
<references> regressiontests/ossfuzz62833/fuzz_set_frame_all-4521858130903040
</references>
<gitfixid>gitfixid: f7c7e84e5a77915bb6570215887118d8e7759122</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202309-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 62547</fuzzer>
<datereported>2023-09-22</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap use after free
</vulnerability>
<description> Calling dwarf_get_fde_for_die() causes the
problem as its special handling in a user calling
for fde destruction is wrong when dwarf_finish()
is calling for fde destruction.
dwarf_finish() can refer to freed memory
in trying to delete a CIE twice.
The use after free has a dependence on the order nodes are seen
in the de_alloc_tree tdestroy() walk of the table
(the order is not predictable).
Broken in release 0.8.0 and all previous releases.
</description>
<datefixed>2023-09-23</datefixed>
<references> regressiontests/ossfuzz62547/fuzz_stack_frame_access-5263709637050368
</references>
<gitfixid>cd741379bd0203a0875b413542d5f982606ae637</gitfixid>
<tarrelease>libdwarf-0.9.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202308-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59576</fuzzer>
<datereported>2023-06-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Read from outside frame section
</vulnerability>
<description> A fuzzed object results in
reading outside a frame section due to a comparison
being > when it should have bin >= at about
line 1615 in dwarf_frame2.
Could result in crash or incorrect frame data returned.
Somehow we lost track of this open bug.
The bug has been in the code since the augmentation
was first implemented in the library.
</description>
<datefixed>2023-08-26</datefixed>
<references> regressiontests/ossfuzz59576/fuzz_set_frame_all-5867083595120640
</references>
<gitfixid>e53adc90ffd6d5d0fad61546b0041990aefd970b</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202307-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 60506</fuzzer>
<datereported>2023-07-09</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Read from outside section
</vulnerability>
<description> A fuzzed object results in
reading outside a line table due to a corruption
in a non-standard (experimental) line table format.
A corrupted offset was not checked for sanity.
The bug has been in the code since the experimental
line table support was added in 2015.
</description>
<datefixed>2023-07-11</datefixed>
<references> regressiontests/ossfuzz60506/fuzz_srcfiles-6494439909228544.fuzz
</references>
<gitfixid>c8c5073f35b1efdcc610ecf369c78f87fdd34714</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-011</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 60090</fuzzer>
<datereported>2023-06-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Read from invalid memory address
</vulnerability>
<description> A fuzzed object results in
an addition overflow in reading CIE data
leading to a read from an invalid address.
An almost-correct check for an overflow
in case of a fuzzed aug_irix_exception_table
augmentation leads to a crash.
The bug was incorrect coding of a test
(for an absurd value) written a few weeks ago.
</description>
<datefixed>2023-06-26</datefixed>
<references> regressiontests/ossfuzz60090/fuzz_set_frame_all-5757752673435648
</references>
<gitfixid>6f75899f1f90fa87e52da0df09ddaa2e5be778f9</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-010</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59950</fuzzer>
<datereported>2023-06-18</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability>library reads outside frame section
</vulnerability>
<description> A fuzzed object results in
adding a too large value (from CIE
frame augmentation data) to a pointer,
having failed to check the value for
reasonableness. That add overflows
so dereferencing the
pointer in dwarf_frame.c could lead to a crash
in the library or getting nonsense information
returned to the caller.
This bug has been present for many years.
</description>
<datefixed>2023-06-19</datefixed>
<references> regressiontests/ossfuzz59950/fuzz_set_frame_all-6613067367317504
</references>
<gitfixid>b7437c9e4923906e9b3f3860a0c8a8289cff0a91</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-009</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59775</fuzzer>
<datereported>2023-06-11</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Fuzzed object results in read past end of section.
</vulnerability>
<description> A fuzzed object results in reading one byte
past the end of a .eh_frame section
in internal function _dwarf_read_loc_expr-op().
Now we check for that before we dereference a pointer
(to read the particular single-byte field).
</description>
<datefixed>2023-06-13</datefixed>
<references> regressiontests/ossfuzz59775/fuzz_die_cu_attrs_loclist-4504718844755968
</references>
<gitfixid>9cae1be75ec333d2b8ab8800df4850ed77a8b025</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-008</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59699</fuzzer>
<datereported>2023-06-08</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Read past end of section
</vulnerability>
<description> In reading a CIE prefix
of a fuzzed object we read past the end
of the section due to a failure
to check a byte pointer before we dereference it
in _dwarf_read_cie_fde_prefix().
</description>
<datefixed>2023-05-10</datefixed>
<references> regressiontests/ossfuzz59699/fuzz_stack_frame_access-6523659305746432
</references>
<gitfixid>c5b909630bb566cdbf68fae4091f049f3b22ff11</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-007</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59602</fuzzer>
<datereported>2023-06-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Buffer overflow read
</vulnerability>
<description> In _dwarf_read_loc_expr_op()
we read one byte past available data
as the required check for past-end
was missing.
</description>
<datefixed>2023-06-10</datefixed>
<references> regressiontests/ossfuzz59602/fuzz_die_cu_attrs_loclist-6737086749999104
</references>
<gitfixid>c8c54ba5c79b0a2687f0fa2ac331479506c3210f</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-006</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59727</fuzzer>
<datereported>2023-06-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Integer Overflow
</vulnerability>
<description> Integer Overflow in
_dwarf_exec_frame_instr() called by
dwarf_expand_frame_instructions.
We now check for overflows in add and
multiply here.
Similar to ossfuzz 59517
</description>
<datefixed>2023-06-08</datefixed>
<references></references>
<gitfixid>f664f93d456284130afbd3c2e35b39e5f2740366</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-005</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59717</fuzzer>
<datereported>2023-06-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Integer Overflow
</vulnerability>
<description> Integer Overflow in
_dwarf_exec_frame_instr() called by
dwarf_expand_frame_instructions.
We now check for overflows in add and
multiply here.
Similar to ossfuzz 59517
</description>
<datefixed>2023-06-08</datefixed>
<references></references>
<gitfixid>f664f93d456284130afbd3c2e35b39e5f2740366</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-004</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59595</fuzzer>
<datereported>2023-06-09</datereported>
<reportedby>shinibufa (github)</reportedby>
<product>libdwarf</product>
<vulnerability> Signed Integer overflow
</vulnerability>
<description> Signed Integer Overflow.
In _dwarf_exec_frame_instr(),
called by dwarf_expand_frame_instructions(),
there was a DW_CFA_LLVM_def_aspace_cfa_sf
and we failed to check for overflow.
The test case had a overflow.
Now we do that check.
</description>
<datefixed>2023-06-10</datefixed>
<references> regressiontests/ossfuzz59595/fuzz_set_frame_all-5319697747542016
</references>
<gitfixid>e8c726e2be644df2706342b7a80633d07ecd7fb4</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-003</dwid>
<cve></cve>
<fuzzer>shinibufa</fuzzer>
<datereported>2023-06-09</datereported>
<reportedby>shinibufa (github)</reportedby>
<product>libdwarf</product>
<vulnerability> use after free
</vulnerability>
<description> Heap use-after-free dwarf_query.c
</description>
<datefixed>2023-05-19</datefixed>
<references> regressiontests/shinibufa/fuzzed_input_file
</references>
<gitfixid>4017ab8b92195641e6876b388cebe2d3307634f5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59519</fuzzer>
<datereported>2023-06-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Integer Overflow
</vulnerability>
<description> Integer Overflow in
_dwarf_exec_frame_instr() called by
dwarf_expand_frame_instructions.
We now check for overflows in add and
multiply here.
Similar to ossfuzz 59517
</description>
<datefixed>2023-06-08</datefixed>
<references> regressiontests/ossfuzz59519/fuzz_set_frame_all-4670829255065600
</references>
<gitfixid>f664f93d456284130afbd3c2e35b39e5f2740366</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202306-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59517</fuzzer>
<datereported>2023-06-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Signed Integer Overflow
</vulnerability>
<description> Nine different places in dwarf_frame.c
multiplied a factored value by a (usually) small integer
without checking if the factored value read from
the object could possibly be real. So the
factored value when multiplied by the factor
could overflow. In some of the cases the factored value
is signed, some it is unsigned.
This sanity checking of factored frame offset
values never existed before in the library.
</description>
<datefixed>2023-06-08</datefixed>
<references> regressiontests/ossfuzz59517/fuzz_set_frame_all-5741671019839488
</references>
<gitfixid>f664f93d456284130afbd3c2e35b39e5f2740366</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-010</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59478</fuzzer>
<datereported>2023-05-31</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory leak in dwarf_expand_frame_instructions()
</vulnerability>
<description> Fuzzing provoked one of four error cases that
could leak locally allocated memory from _dwarf_exec_frame_instructor()
(called by dwarf_expand_frame_instructions).
The code did free(localregtab) but
needed to do FREELOCALMALLOC, a macro specific
to this function which cleans up all local allocations.
All four places have been corrected.
Called enough times with fuzzed data could result
in filling memory leading to the library being unable
to work for the caller and instead just returning errors.
This bug has been present in the code for many years.
</description>
<datefixed>2023-05-31</datefixed>
<references> regressiontests/ossfuzz59478/fuzz_set_frame_all-5300774457180160
</references>
<gitfixid>8ef9c8fb613e59f534e789e91a73088eaa5b8a5a</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-009</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56451</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Write to memory fails
</vulnerability>
<description> One problem is a bug in the test source:
fuzz/fuzz_dnames.c. It calls dwarf_dnames_abbrevtable()
incorrectly. The caller is required to provide arrays
dw_idxattr_array and dw_form_array and pass a pointer to such.
The code was just passing in a pointer to nothing.
The library code has no possible way to determine the passed
in pointers are usable.
In addition, dwarf_dnames_abbrevtable() did not
check that pointers passed in were non-null before
use, but now it does.
</description>
<datefixed>2023-05-30</datefixed>
<references> regressiontests/ossfuzz56451/fuzz_dnames-4986494365597696
</references>
<gitfixid>12a612fc8db38fc26cd5e6064f09a6f825891c7c</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-008</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56492</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>fuzz testing</product>
<vulnerability> Timeout (exceeds 50 seconds)
</vulnerability>
<description> The problem is a bug in the test source:
fuzz/fuzz_macro_dwarf5.c. One must not blame the
fuzzer author for examplep5(),
the code was based on doc/checkexamples.c
and there examplep() was really just a sketch.
The testcase here no longer specifies an infinite loop.
</description>
<datefixed>2023-05-23</datefixed>
<references> regressiontests/ossfuzz56492/fuzz_macro_dwarf5-6497277180248064
</references>
<gitfixid>97a78122268c9a74701f2dd3115f902309e9a484</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-007</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56474</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null pointer dereference.
</vulnerability>
<description> Calling dwarf_highpc_b() lead to crash.
The function was dereferencing an argument before
the argument was checked. Now it is checked
for null before any dereference.
In addition, the test code, fuzz/fuzz_die_cu_attrs_loclist.c,
called dwarf_highpc_b() with a Dwarf_Die that is
uninitialized local variable (hence contents unpredictable).
C code has no way to catch such a caller error.
This is a bug in the test code.
We are changed the test code local data pointer variable
to be initialized with the value 0.
</description>
<datefixed>2023-05-23</datefixed>
<references> regressiontests/ossfuzz56474/fuzz_die_cu_attrs_loclist-4719938125561856
</references>
<gitfixid>b3df2530732ea515cda5a85438871e15c6723ead</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-006</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56472</fuzzer>
<datereported>2023-02-27</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Crash on null pointer argument.
</vulnerability>
<description> A call to any dwarf_get_fission
or any API entry with _xu_ in the name
(functions for DWARF5 Debug Fission, called Split Dwarf
in DWARF5) would crash the caller if any relevant argument
was null. The problem has existed since the code
was written in 2021.
Once that is fixed valgrind complains about using
an uninitialized value.
fuzz/fuzz_simplereader_tu.c calls libdwarf with
the declation being Dwarf_Die die; no initializer
present. Bad behavior, even a library crash is
likely.
</description>
<datefixed>2023-05-30</datefixed>
<references> regressiontests/ossfuzz56472/fuzz_simplereader_tu-6614412934119424
</references>
<gitfixid>8b17d41a31c33e0b3b9727a8044e0093a754d6d7</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-005</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56462</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Unpredictable crash or erroneous data returned
</vulnerability>
<description> A call to dwarf_set_frame_undefined_value()
dwarf_set_frame_rule_initial_value() dwarf_set_frame_same_value()
dwarf_set_frame_cfa_value() dwarf_set_frame_rule_table_size()
with unusable values was not being caught.
Now if the set of values violates the required
relationships an error is returned on requesting
actual frame data.
The problem has existed for many years (fixed May 23).
Once that is fixed valgrind shows leaks. That is because
fuzz/fuzz_set_frame_all.c fails to call dwarf_finish() and,
instead, simple exit()s at several places. Updated the
test source to return from its functions and only
exit() from main() after the dwarf_finish() call.
</description>
<datefixed>2023-05-30</datefixed>
<references> regressiontests/ossfuzz56462/fuzz_set_frame_all-5424385441005568
</references>
<gitfixid>21b33d13024d18b09e32914ca5718a5c81d1ad67</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-004</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56446</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf test code</product>
<vulnerability> Incorrect section bound check
</vulnerability>
<description> The test program fuzz_dnames.c passed
a non-null pointer containing garbage content.
The fix is to initialize (in fuzz_dnames.c)
the local variable to null (0).
</description>
<datefixed>2023-05-23</datefixed>
<references> regressiontests/ossfuzz56446/fuzz_dnames-4784811358420992
</references>
<gitfixid>6fac1021c67d72da6b65f99ad815978d40b4c1e8</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-003</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 59091</fuzzer>
<datereported>2023-05-19</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Incorrect section bound check
</vulnerability>
<description> A fuzzed line table in the non-standard
(experimental) two-level line table format
exposed a failure as the test was v > sectionend
whereas it has to be v >= sectionend as end pointers
are always one-past the end of the area.
This was incorrect since the experimental table support
was added in 2021.
</description>
<datefixed>2023-05-19</datefixed>
<references> regressiontests/ossfuzz59091/fuzz_macro_dwarf5-5135813562990592
</references>
<gitfixid>4017ab8b92195641e6876b388cebe2d3307634f5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 58797</fuzzer>
<datereported>2023-05-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory Leak reading experimental line table
</vulnerability>
<description> A fuzzed line table in the non-standard
(experimental) two-level line table format had
several unchecked values and one was larger than
made any sense, and detecting the error revealed
a memory leak. Caused by the incomplete fix to
DW202305-001 (yesterday).
This is was a failure to run some crucial tests,
which would have exposed the problem before
DW202305-001 was completed. Incomplete testing.
</description>
<datefixed>2023-05-10</datefixed>
<references> regressiontests/ossfuzz58797/fuzz_macro_dwarf5-4872686367801344
</references>
<gitfixid>eeb935200f78b8509e6b1837f6825b9d551b9f7d</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202305-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 58769</fuzzer>
<datereported>2023-05-09</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Excessive malloc reading experimental line table
</vulnerability>
<description> A fuzzed line table in the non-standard
(experimental) two-level line table format had
several unchecked values and one was larger than
made any sense.
The failure was due to oss-fuzz limiting malloc to 3GB.
The failure was appropriate as the fuzzed values were
inappropriate. We now check for sensible values.
See libdwarf/dwarf_line_table_reader_common.h
The code was in libdwarf starting in 2021.
</description>
<datefixed>2023-05-09</datefixed>
<references> regressiontests/ossfuzz58769/fuzz_macro_dwarf5-5460713058205696
</references>
<gitfixid>edc241bd0bf22c94d2d496f3cb761e60f066cd14</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202304-004</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 58026</fuzzer>
<datereported>2023-04-15</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Segv on unknown address reading frame data.
</vulnerability>
<description> On reading a corrupt frame register number
the library could crash with a segmentation violation.
This bug has been present in the code for 25 years.
The conversion of an impossibly large
(carefully constructed) register number
to a Dwarf_Half or unsigned int the result looked
reasonable, invalidating some tests for
reasonableness. Now we do all the tests
on the full Dwarf_Unsigned register number(s)
and retain the value in the long form everywhere.
Fixed 2023-04-15.
Once that is fixed there is still a leak found by valgrind.
Tht test code fuzz/fuzz_set_frame_all.c does a local
malloc and in some cases returned without free-ing it
locally. Now that local malloc has the necessary
local free.
</description>
<datefixed>2023-05-30</datefixed>
<references> regressiontests/ossfuzz58026/fuzz_set_frame_all-4582976972521472.fuzz
</references>
<gitfixid>21b33d13024d18b09e32914ca5718a5c81d1ad67</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202304-003</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57887</fuzzer>
<datereported>2023-04-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Reading outside the intended section data.
</vulnerability>
<description> Crash in libdwarf on reading
.debug_addr given a bogus index entry.
Due to failing to correctly check that the index is
out of range.
The index was close to overflowing Dwarf_Unsigned
so testing values *after* arithmetic done on the
incoming index was too late:
so we read outside the .debug_addr table.
The checks have been incomplete since this DWARF5 section
code was written. libdwarf/dwarf_query.c
</description>
<datefixed>2023-04-11</datefixed>
<references> regressiontests/ossfuzz57887/fuzz_die_cu-4866423964172288
</references>
<gitfixid>1729d9af3f690bece912ae0f625b312566d0ae25</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202304-002</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57766</fuzzer>
<datereported>2023-04-07</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow
</vulnerability>
<description> Crash in libdwarf on reading an attribute
due to failing to check that an index into .debug_str_offsets
is sane. So we read far outside the relevant table.
The checks have been incomplete since this DWARF5 section
code was written. Two functions in libdwarf
dwarf_form.c had the same problem.
</description>
<datefixed>2023-04-09</datefixed>
<references> regressiontests/ossfuzz57766/fuzz_die_cu_print-5295062170075136
</references>
<gitfixid>761da806fc950c6b26c1763e8989a814e9b16a59</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202304-001</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57711</fuzzer>
<datereported>2023-04-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> dereference null pointer
</vulnerability>
<description> Crash in libdwarf on dwarf_srcfiles() call.
A dereference off a null pointer due to corrupt
file numbers not being noticed. Any such crash left an
incomplete and misleading stack trace.
The large numbers treated as Dwarf_Signed were part of the problem.
Now in libdwarf we check Dwarf_Signed for negative values and issue
an error if the value less than 0. So later casts to
Dwarf_Unsigned work as intended.
The libdwarf problems have been in the library for a very
long time.
</description>
<datefixed>2023-04-06</datefixed>
<references> regressiontests/ossfuzz57711/fuzz_srcfiles-4695324781576192
</references>
<gitfixid>da0d1efbeddcff23c25704bd9672e98314928b19</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-059</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57562</fuzzer>
<datereported>2023-03-30</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Infinite loop reading DIEs
</vulnerability>
<description> Caller looping on dwarf_siblingof_b()
(wanting to touch all siblings)
could be put in an infinite loop.
A DW_AT_sibling attribute with a corrupted
attribute value meant the caller never sees
the DW_DLV_NO_ENTRY return signalling all siblings
have been seen.
</description>
<datefixed>2023-04-01</datefixed>
<references> regressiontests/ossfuzz57562/fuzz_findfuncbypc-6681114772373504
</references>
<gitfixid>21b076f652992c03f145f6edeb623918e17693f8</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-058</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57527</fuzzer>
<datereported>2023-03-29</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> reading off end of valid data can crash library
</vulnerability>
<description> A line table header truncated by a fuzzer
to just the right length (anywhere within a 12 byte area)
would cause memory references outside of valid data.
Now we check there is object data present
before referring to that area and if not, return
an error.
</description>
<datefixed>2023-03-30</datefixed>
<references> regressiontests/ossfuzz57527/fuzz_srcfiles-4599045397282816
</references>
<gitfixid>36e4063ade31c9ea6ea5df973d2045b36877885b</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-057</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2023-03-26</datereported>
<reportedby>Pedro Navarro</reportedby>
<product>libdwarf</product>
<vulnerability> Unable to read large object sections
</vulnerability>
<description> A section 2GB+ in size could not be
read by libdwarf. Such is a Denial of Service.
Simply turning the big read
into however many are needed (each below 2GB)
was simple to do. The limitation in the 'read'
libc function (really a Linux kernel
limitation) is well documented but
we had not noticed before now.
Few object files are so large.
</description>
<datefixed>2023-03-28</datefixed>
<references></references>
<gitfixid>8bf96199a0e130483cceca6bfacfbe4127441ab1</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-056</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57516</fuzzer>
<datereported>2023-03-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference in dwarf_hasattr()
</vulnerability>
<description> With a corrupted attribute
dwarf_hasattr() could try to access
an implicit_const abbrev value indexing
off of a NULL library internal pointer.
Because the abbrev section had no actual implicit
const value due to the corruption, so the internal
array for holding such was not present.
The pointer abl_implicit_const was NULL.
Now we test the pointer for NULL and if NULL
report an error.
This lack of a NULL check has existed
for many years.
</description>
<datefixed>2023-03-29</datefixed>
<references> regressiontests/ossfuzz57516/fuzz_die_cu_attrs-6171488289161216
</references>
<gitfixid>5dc3de5ce70331692a2700b218fb79e0d4d81c23</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-055</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57485</fuzzer>
<datereported>2023-03-27</datereported>
<reportedby>David Korczynski</reportedby>
<product>None, test code bug</product>
<vulnerability></vulnerability>
<description> Abort in fuzz_die_cu_attrs.c
The fault was in test code.
Since fixed (earlier today). No code change here.
</description>
<datefixed>2023-03-28</datefixed>
<references> regressiontests/ossfuzz57485/
</references>
<gitfixid>2b19bc239f3cedd1b2461e4265d90633277ce704</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-054</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57463</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>none, test code bug</product>
<vulnerability> dereference null in test code
</vulnerability>
<description> The fault was in test code.
fuzz_die_cu_attrs.c
Since fixed (earlier today). No code change here.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57463/fuzz_die_cu_attrs-5158380196200448
</references>
<gitfixid>e4053c9a0f25db0bed28372d9b77a50a0307dc10</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-053</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57443</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Double free in _dwarf_read_line_table_header
</vulnerability>
<description> The same bug seen earlier
A double free when a particular error is
in the line table header.
Fixed already.
gitfixid is more recent than truly required.
</description>
<datefixed>2023-03-28</datefixed>
<references> regressiontests/ossfuzz57443/fuzz_srcfiles-6015429578719232
</references>
<gitfixid>c25a14c3fd5522aff0b1d2a77d7ee66b7c529779</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-052</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57442</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> Corrupt .debug_rngslists leads to crash
when a rnglists header has a length indicating
a longer section than we really have.
Now we check more carefully for that situation.
The bug existed from 2017, when DWARF5 support
was added to the library.
</description>
<datefixed>2023-03-28</datefixed>
<references> regressiontests/ossfuzz57442/fuzz_rng-5974595378479104
</references>
<gitfixid>271b9b8367a8151fcd98723d73382ec56f05c810</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-051</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57437</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap double free
</vulnerability>
<description> In a specific error case
reading a fuzzed object and calling
dwarf_srcfiles local data was
freed twice. The bug was
fixed earlier, and involved
src/lib/libdwarf/dwarf_line_table_reader_common.h.
</description>
<datefixed>2023-03-28</datefixed>
<references> regressiontests/ossfuzz57437/fuzz_srcfiles-5281689109921792
</references>
<gitfixid>c25a14c3fd5522aff0b1d2a77d7ee66b7c529779</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-050</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57429</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> invalid free() in test source
</vulnerability>
<description> The test source violates libdwarf requirements.
fuzz/fuzz_die_cu_attrs.c was doing free on a name pointer
returned from dwarf_diename. The documentation clearly
states that pointer should not have a free() done.
fix id below is fixing the test source.
</description>
<datefixed>3023-03-28</datefixed>
<references> regressiontests/ossfuzz57429/fuzz_die_cu_attrs-4845537731149824
</references>
<gitfixid>2b19bc239f3cedd1b2461e4265d90633277ce704</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-049</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57408</fuzzer>
<datereported>2023-03-24</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Stack Overflow, _dwarf_create_a_new_cu_context...
</vulnerability>
<description> involves find_sig8_target_as_global_offset()
and is the same problem as seen in other guises earlier.
The case becomes an infinite loop, so eventually the
stack gets exhausted. Fixed.
See also ossfuzz id 56540. ossfuzz id 56487. ossfuzz id 56497.
ossfuzz 57480
</description>
<datefixed>2023-03-26</datefixed>
<references> regressiontests/ossfuzz57408/fuzz_die_cu-4702098356043776
</references>
<gitfixid>24f5697aecd77092de20f0f7e7d91fbc1f2b3da0</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-048</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Memory leak (was double free).
</vulnerability>
<description> The command:
dwarfdump --file-name=<file> -kG -ka <objectfile>
results in a a memory leak.
In certain error cases we failed to fclose()
a FILE * used to read dwarfdump.conf.
Earlier changes fixed the double free, this
fixes the memory leak..
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/choi015/poc_file_03
</references>
<gitfixid>24f5697aecd77092de20f0f7e7d91fbc1f2b3da0</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-047</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Double Free
</vulnerability>
<description> The command:
dwarfdump --check-unique --check-abbrev
results in a double free.
The table of unique errors contained
makename() data, so that aspect caused
a double free as makename gets destructed
independently. Fixed now,letting makename
destructor do the work.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/choi015/poc_file_04
</references>
<gitfixid>df64db4740f1b480e602b1112107d51f0d269828</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-046</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> global buffer overflow
</vulnerability>
<description> The command:
dwarfdump --search-regex=t[ą--]e
Note the non-ascii character.
The dwarfdump regex only allows ascii
in search patterns, not the rest of UTF-8.
</description>
<datefixed>2023-03-26</datefixed>
<references> regressiontests/choi012/poc_file_10
</references>
<gitfixid>9eac0c8bbae3fadb2be3d5ee15b9c44f42d2f966</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-045</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Heap buffer overflow, regex
</vulnerability>
<description> The command:
dwarfdump --search-regex=
with a simple, really long, string.
(with no file named)
resulted in a buffer overflow in a buffer
in dd_regex.c.
No object file is required for the test.
The code now checks stores to the internal array
holding the non-deterministic finite automata (nfa)
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/baselines/choi014.base
</references>
<gitfixid>bb8fab9e5e4e40b1268b31d90882c2ab93653eaf</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-044</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> The command:
dwarfdump --search-regex=\\
(with no file named)
resulted in a heap use after free.
No object file is required for the test.
The dd_regex.c regex compiler failed
to notice when a trailing backslash
caused the pattern compiler to step
past the pattern string.
Now we notice and issue an error.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/baselines/choi013.base
</references>
<gitfixid>3269f43d2a044bfcce71d30ce214a305473d1ea3</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-043</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Use After Free
</vulnerability>
<description> The command:
dwarfdump choi012/poc_file_08
was resulting in a heap use after free.
It no longer does, due to earlier
libdwarf fixes.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/choi012/poc_file_08
</references>
<gitfixid>4a8a201cdb3408a2cfdc2946418b51b884140a2c</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-042</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Memory Leak
</vulnerability>
<description> The command:
dwarfdump --check-all choi012/poc_file_07
leaked memory in dwarfdump.
A single instance of print_error_and_continue()
failed to return DW_DLV_ERROR when libdwarf
reported an error.
Before recent fixes to libdwarf this would
also generate heap-use-after-free.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/choi012/poc_file_07
</references>
<gitfixid>4a8a201cdb3408a2cfdc2946418b51b884140a2c</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-041</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-08</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Heap Use after Free
</vulnerability>
<description> The command:
dwarfdump --check-frame-extended choi012/poc_file_06
is now working, apparently fixed by earlier
bug fixes in libdwarf.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/choi012/poc_file_06
</references>
<gitfixid>fd92b647e5e3a524be94b3b06c9efd14a8292946</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-040</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-07</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Reading from zero page
</vulnerability>
<description> The command: dwarfdump --file-abi=
causes big problems. Denial of service.
For many of such commands with an '=' and nothing
following the
dwoptarg variable is not set at all, leading
to a segmentation violation.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/choi011/README
</references>
<gitfixid>fd92b647e5e3a524be94b3b06c9efd14a8292946</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-039</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56480</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Reading a compilation unit never finishes
</vulnerability>
<description> Reading a DWARF compilation unit header
in a corrupted object
caused an infinite loop of repeated calls (growing the stack
at each call) in libdwarf. Now the library properly reflects
a NO ENTRY case avoiding the loop and the test case returns
an unrelated error due to other corruption.
Arguably the loop was due to corruption too, but it should
not have gotten stuck in the loop (and now it will not
get stuck).
See also ossfuzz id 56540. ossfuzz id 56487. ossfuzz id 56497.
ossfuzz 57408
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56480/fuzz_die_cu_print-5264022485467136
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-038</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57335</fuzzer>
<datereported>2023-03-22</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference in dwarf_hasform()
</vulnerability>
<description> Passing a null dw_return_bool pointer dereferenced
zero, but now, instead we return DW_DLV_ERROR with error code
DW_DLE_INVALID_NULL_ARGUMENT
The test driver fuzz_die_cu_attrs.c passed in a NULL
argument (the test was not modified except for adding
a comment) but libdwarf now checks for a null argument.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57335/fuzz_die_cu_attrs-6235345560928256.fuzz
</references>
<gitfixid>e4053c9a0f25db0bed28372d9b77a50a0307dc10</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-037</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57300</fuzzer>
<datereported>2023-03-21</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out of Memory
</vulnerability>
<description> Another case of the infinite loop
due to _dwarf_find_CU_Context_given_sig().
See DW202303-034 57193 and others listed here.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57300/fuzz_die_cu-4752724662288384
</references>
<gitfixid>7165918c8594061c3f5ba7dd4df7c4555c68ec78</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-036</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57300</fuzzer>
<datereported>2023-03-15</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out of Memory
</vulnerability>
<description> Another case of the infinite loop
due to _dwarf_find_CU_Context_given_sig().
See DW202303-034 57193
See DW202303-034 57149
See DW202303-034 57193
See DW202303-034 57292
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57300/fuzz_die_cu-4752724662288384
</references>
<gitfixid>7165918c8594061c3f5ba7dd4df7c4555c68ec78</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-035</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57292</fuzzer>
<datereported>2023-03-15</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out of Memory
</vulnerability>
<description> Another case of the infinite loop
due to _dwarf_find_CU_Context_given_sig().
See DW202303-034 57193 and others listed here.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57292/fuzz_die_cu_print-5412313393135616
</references>
<gitfixid>7165918c8594061c3f5ba7dd4df7c4555c68ec78</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-034</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57193</fuzzer>
<datereported>2023-03-15</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Infinite loop till out of memory.
</vulnerability>
<description> The infinite loop reading a fuzzed object file
was caused by letting internal function
_dwarf_find_CU_Context_given_sig()
unconditionally do too much in the middle
of setting up a CU_Context (by letting
it start more CU_contexts().
The implicit infinite loop has been there
a few years, depending on the correctness
of object files DWARF4/DWARF5 being read.
Same bug as ossfuzz 57107, ossfuzz 57149.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57193/fuzz_die_cu_offset-5215024489824256
</references>
<gitfixid>7165918c8594061c3f5ba7dd4df7c4555c68ec78</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-033</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57149</fuzzer>
<datereported>2023-03-15</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Stack overflow
</vulnerability>
<description> Infinite loop till out of memory
Similar to 57107 DW202303-032 but revealed
there were more places in find_cu_die_base_fields that
needed to call the internal _dwarf_internal_global_formref_b()
function.
The bug was present since 2017, when DWARF5 support for
new 'base' fields was created.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz57149/fuzz_srcfiles-6213793811398656
</references>
<gitfixid>7165918c8594061c3f5ba7dd4df7c4555c68ec78</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-032</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57107</fuzzer>
<datereported>2023-03-14</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Infinite loop till out of memory.
</vulnerability>
<description> The infinite loop reading a fuzzed object file
was caused by letting internal function
_dwarf_find_CU_Context_given_sig()
unconditionally do too much in the middle
of setting up a CU_Context (by letting
it start more CU_contexts().
The implicit infinite loop has been there
a few years, depending on the correctness
of object files DWARF4/DWARF5 being read.
</description>
<datefixed>2023-03-23</datefixed>
<references> regressiontests/ossfuzz57107/fuzz_die_cu_attrs_loclist-4991396240293888
</references>
<gitfixid>0c92ef5b66c5bbcacae03fbf355b12713151c098</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-031</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57048</fuzzer>
<datereported>2023-03-14</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability></vulnerability>
<description> Calling dwarf_next_cu_header_d() on a corrupted
object file results in an infinite loop
and (eventually) a crash in dwarf_xu_index.c attempting
to resolve an 8 byte hash key.
The bug existed from the first version of this source file.
The same bug as DW202303-030.
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz57048/fuzz_findfuncbypc-4647942385696768
</references>
<gitfixid>774f98e596df9dd8f3cb92ec76243caaa4287039</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-030</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 57027</fuzzer>
<datereported>2023-03-12</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Infinite loop reading a gnu index section.
</vulnerability>
<description> Calling dwarf_next_cu_header_d() on a corrupted
object file results in an infinite loop
and (eventually) a crash in dwarf_xu_index.c attempting
to resolve an 8 byte hash key.
The bug existed from the first version of this source file,
which was in 2017 as the data involved DWARF5, new in 2017.
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz57027/fuzz_stack_frame_access-5123569972805632
</references>
<gitfixid>774f98e596df9dd8f3cb92ec76243caaa4287039</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-029</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56993</fuzzer>
<datereported>2023-03-12</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Leaked Memory
</vulnerability>
<description> Calling dwarf_get_macro_context on a particular
fuzzed object file results in a memory leak when
a particular error in the corrupted section is detected.
The malloc was done by the line table reader code.
The bug was there for many years
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz56993/fuzz_macro_dwarf5-5770464300761088
</references>
<gitfixid>5fde5e404a98c6727889cf14d8f93ec2138a6fa</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-028</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56958</fuzzer>
<datereported>2023-03-12</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out of memory crash.
</vulnerability>
<description> Failing to check for error conditions
in a fuzzed object correctly lead to a giant malloc
that could not succeed.
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz56958/fuzz_stack_frame_access-6097292873826304
</references>
<gitfixid>b9393bb9b6399a34f8616a272d030bdd004a5ef5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-027</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56906</fuzzer>
<datereported>2023-03-09</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer overflow reading rnglists section.
</vulnerability>
<description> Calling dwarf_get_rnglist_rle() on a corrupted
object file could result in a library crash.
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz56906/fuzz_rng-6031783801257984.fuzz
</references>
<gitfixid>b9393bb9b6399a34f8616a272d030bdd004a5ef5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-026</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56897</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow reading the rnglists section
</vulnerability>
<description> dwarf_get_rnglist_offset_index_value() could fail
on a corrupt object due to imprecise calculations of
entry offsets. Fixed by a major update of the code
in dwarf_rnglists.c
</description>
<datefixed>2023-03-22</datefixed>
<references> regressiontests/ossfuzz56897/fuzz_rng-5105415777288192
</references>
<gitfixid>b9393bb9b6399a34f8616a272d030bdd004a5ef5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-025</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56895</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow reading compilation unit header.
</vulnerability>
<description> Calling dwarf_next_cu_header_d() on the fuzzed test
object results in a library crash in fuzz_die_cu_attrs_loclist.c
due to a failure to
precisely test for a too-short Compilation Unit header.
Now a DW_DLV_ERROR is returned.
A very old bug.
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz56895/fuzz_macro_dwarf5-5080340952907776
</references>
<gitfixid>771cfcca1ef6a4a7eb9595d700fc72020d0ed72e</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-024</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56807</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory Leak in dwarf_check_lineheader_b()
</vulnerability>
<description> The fuzzed test object file resulted
in a memory leak calling dwarf_check_lineheader_b()
as called from fuzz_srcfiles.c
Two error conditions in dwarf_line_table_reader_common.h
were missing a required free().
</description>
<datefixed>2023-03-24</datefixed>
<references> regressiontests/ossfuzz56807/fuzz_srcfiles-4626047380619264
</references>
<gitfixid>484f50ef8be0506be2e4b5fbad489868db5c7985</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-023</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56568</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>Test harness</product>
<vulnerability> Test build failure
</vulnerability>
<description> The fuzz_dnames.c testcase build failed.
A result of removing two functions from the API,
dwarf_dnames_abbrev_by_code() and
dwarf_dnames_abbrev_form_by_index().
Removed 2023-02-23.
The test source no longer uses those two functions.
The first was slow and hard to use. The second
was unusable and never worked. The documentation
(libdwarf.pdf) gives alternates in the library that work.
</description>
<datefixed>2023-03-20</datefixed>
<references></references>
<gitfixid>2eced75af9903ab778c3b237ec7be3ddc93ea6ec</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-022</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56497</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>test harness</product>
<vulnerability> Memory Leak
</vulnerability>
<description> The leak was due to the test driver fuzz/fuzz_rng.c
failing to call dwarf_finish at the point of returning as a result
of the corrupted binary returning an error condition.
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56497/
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-021</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56487</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>testing harness</product>
<vulnerability> Memory Leak
</vulnerability>
<description> The leak was due to the test driver fuzz/fuzz_rng.c
failing to call dwarf_finish at the point of returning as a result
of the corrupted binary returning an error condition.
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56487/clusterfuzz-testcase-fuzz_rng-6655451078197248
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-020</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56458</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> The overflow encountered when
reading a corrupted line table header in read_a_name_table_header in
dwarf_debugnames.c
There was insufficient checking for out of bounds
values.
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56458/fuzz_findfuncbypc-5073632331431936
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-019</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56454</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Stack buffer overflow
</vulnerability>
<description> The overflow was in dwarf_get_version_of_die()
One return failed to free a local malloc due to the
particular corruption in the text object DWARF.
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56454/
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-018</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56807</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Memory leak reading line table
</vulnerability>
<description> A memory leak in _dwarf_read_line_table()
reading a particular corrupted object.
One return failed to free a local malloc.
An very old bug, encountered reading corrupted
DWARF line tables.
</description>
<datefixed>2023-03-20</datefixed>
<references> regressiontests/ossfuzz56807fuzz_srcfiles-4626047380619264
</references>
<gitfixid>1ff4365bd64a4e4f9ab717b3f62589c2ba6637a5</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-017</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56450</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Stack Buffer Overflow
</vulnerability>
<description> Stack buffer overflow in dwarf_dietype_offset.
Reading a corrupted object file.
The bug was in the test code, not libdwarf.
Having fixed that, valgrind finds that some memory is not
freed by dwarf_finish(). In dwarf_alloc.c March 20
_dwarf_free_all_of_one_debug() if the Dwarf_Debug was normal
we failed to call _dwarf_free_static_errlist() and that
left memory allocated from a bogus earlier call to the
library (a situation libdwarf should handle and now does).
</description>
<datefixed>2023-05-30</datefixed>
<references> regressiontests/ossfuzz56450/fuzz_die_cu_attrs-4953133005799424
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-016</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56476</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow in dwarf_get_rnglist_offset_value
</vulnerability>
<description> A heap buffer overflow reading
a fuzzed object file
A revision of dwarf_str_offsets (which was
new in DWARF5) affected several source files
</description>
<datefixed>2023-03-12</datefixed>
<references> regressiontests/ossfuzz56476/fuzz_rng-5008229349588992/
</references>
<gitfixid>0343c63bd04d387924974e6da60d8471fdf945a9</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-015</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56489</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow in read_single_rle_entry
</vulnerability>
<description> A heap buffer overflow reading
a fuzzed object file
A revision of dwarf_str_offsets (which was
new in DWARF5) affected several source files
</description>
<datefixed>2023-03-12</datefixed>
<references> regressiontests/ossfuzz56489/fuzz_srcfiles-5091530466787328
</references>
<gitfixid>0343c63bd04d387924974e6da60d8471fdf945a9</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-014</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56478</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow in read_single_rle_entry
</vulnerability>
<description> A heap buffer overflow reading
a fuzzed object file
A revision of dwarf_str_offsets (which was
new in DWARF5) affected several source files
</description>
<datefixed>2023-03-12</datefixed>
<references> regressiontests/ossfuzz56478/fuzz_rng-5030515398017024
</references>
<gitfixid>0343c63bd04d387924974e6da60d8471fdf945a9</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-013</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56460</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow
</vulnerability>
<description> A heap buffer overflow reading
a fuzzed object file
A revision of dwarf_str_offsets (which was
new in DWARF5) affected several source files
</description>
<datefixed>2023-03-12</datefixed>
<references> regressiontests/ossfuzz56460/fuzz_str_offsets-5376904040677376-5240324382654464
</references>
<gitfixid>0343c63bd04d387924974e6da60d8471fdf945a9</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-012</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56456</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap Buffer Overflow
</vulnerability>
<description> A heap buffer overflow reading
a fuzzed object file
Code reading the gdbindex section was not
fully checking for valid offsets and pointers
Duplicate of DW202303-006
</description>
<datefixed>2023-03-14</datefixed>
<references> regressiontests/ossfuzz56456/fuzz_gdbindex-5240324382654464
</references>
<gitfixid>e564c9350c104f16eb2223d7b29082e3deb5d2fb</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-011</dwid>
<cve></cve>
<fuzzer>ossfuzz id: 56453</fuzzer>
<datereported>2023-02-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null pointer dereference
</vulnerability>
<description> A null pointer dereference in
reading a fuzzed object file.
This is related to checks for a correct
value from the READ_AREA_LENGTH macro.
The missing checks have been missing a very
long time.
</description>
<datefixed>2023-03-07</datefixed>
<references> regressiontests/ossfuzz56453
</references>
<gitfixid>86671059c1c240ae56433fa94993dcd28df2ae7d</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-010</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2023-03-07</datereported>
<reportedby>Youngseok Choi</reportedby>
<product>dwarfdump</product>
<vulnerability> Stack overflow dwarfdump
</vulnerability>
<description> A wholly corrupted speically constructed
dwarfdump.conf which is entirely inappropriate ascii
really made a mess of one's screen.
Now after a couple lines of garbage we
give up on that conf file. And we print the garbage
sanitized to avoid messing up one's screen.
The fix also avoids buffer overflow.
</description>
<datefixed>2023-03-25</datefixed>
<references> regressiontests/choi010/poc_file
</references>
<gitfixid>cb8dd45770f2e1f440aab60adac0256f268fc16e</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-009</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56443</fuzzer>
<datereported>2023-03-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt line table header
</vulnerability>
<description> With any one of a small set of corrupted data
fields in a line table header that were not checked
for sanity the library could try to malloc a giant space,
which could take a long time to succeed or fail.
After that almost anything could happen.
Same as ossfuzz 56548.
With the bug in 56548 fixed, now we still have a bug,
there is a leak from _dwarf_special_no_dbg_error_malloc()
-fsanitize does not show the bug here, but valgrind does
</description>
<datefixed>2023-05-29</datefixed>
<references> regressiontests/ossfuzz56443/fuzz_crc_32-4750941179215872
</references>
<gitfixid>241fe0cb415569975c451d1f2d62fb2b2147cd72</gitfixid>
<tarrelease>libdwarf-0.8.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-008</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56530</fuzzer>
<datereported>2023-03-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of Service with corrupt attribute
</vulnerability>
<description> With a particular data corruption
dwarf_attrlist() failed to return an error and
the library would dereference a stale pointer.
This also provoked a memory leak.
Same bug as DW202303-001
</description>
<datefixed>2023-03-02</datefixed>
<references> ossfuzz56530/fuzz_findfuncbypc-6272642689925120
</references>
<gitfixid>948352178dc791796ed574a961191844d8322493</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-007</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56735</fuzzer>
<datereported>2023-03-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt debug_macro section.
</vulnerability>
<description> We were not checking .debug macro data for a
corrupted internal macro length field. Now we check.
</description>
<datefixed>2023-03-08</datefixed>
<references> regressiontests/ossfuzz56735/fuzz_macro_dwarf5-6718585377783808
</references>
<gitfixid>bb99fe7ddb2bc6601bcb0ee30ced6a8cc8cb0564</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-006</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56456</fuzzer>
<datereported>2023-03-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service (crash) looking for gdbindex section.
</vulnerability>
<description> The logic was wrong in a couple places (fixed now)
and almost nothing was checked for validity. Now we check,
so to libdwarf do not result in a crash of the library.
The bugs have been there since the code was written
in 2014.
</description>
<datefixed>2023-03-14</datefixed>
<references> regressiontests/ossfuzz56456/fuzz_gdbindex-5240324382654464
</references>
<gitfixid>e564c9350c104f16eb2223d7b29082e3deb5d2fb</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-005</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56676</fuzzer>
<datereported>2023-03-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt frame section.
</vulnerability>
<description> A call to dwarf_expand_frame_instructions()
with corrupt data gets a segmentation violation.
</description>
<datefixed>2023-03-14</datefixed>
<references> regressiontests/ossfuzz56676/fuzz_set_frame_all-5081006119190528.fuzz
</references>
<gitfixid>e564c9350c104f16eb2223d7b29082e3deb5d2fb</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-004</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56666</fuzzer>
<datereported>2023-03-04</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt gnu_index section
</vulnerability>
<description> A corrupted .debug_gnu_index header was not
properly checked, and the calculation setting
up the table in memory was not correctly set up.
</description>
<datefixed>2023-03-08</datefixed>
<references> regressiontests/ossfuzz56666/fuzz_gnu_index-4803574417981440
</references>
<gitfixid>64eaaa58703258cab02896e798664a1bb11a3d5c</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-003</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56636</fuzzer>
<datereported>2023-03-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt .debug_addr section
</vulnerability>
<description> A corrupted .debug_addr header was not
properly checked, and the calculation setting
up the table in memory was not correctly set up.
Calling dwarf_debug_addr_by_index() could crash the calling
application.
</description>
<datefixed>2023-03-03</datefixed>
<references> regressiontests/ossfuzz56636/fuzz_debug_addr_access-4801779658522624.fuzz
</references>
<gitfixid>a3ab3f16ab67f4d976561fe0d863e1ed8b71f3c6</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-002</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56548</fuzzer>
<datereported>2023-03-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with corrupt line table header
</vulnerability>
<description> With any one of a small set of corrupted data
fields in a line table header that were not checked
for sanity the library could try to malloc a giant space,
which could take a long time to succeed or fail.
After that almost anything could happen.
Same bug fix as 56443
</description>
<datefixed>2023-03-03</datefixed>
<references> regressiontests/ossfuzz56548/fuzz_findfuncbypc-5073632331431936
</references>
<gitfixid>89d3beccd161657760585967255bbabf67e5b4c9</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202303-001</dwid>
<cve></cve>
<fuzzer>oss-fuzz id: 56465</fuzzer>
<datereported>2023-03-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of Service with corrupt attribute
</vulnerability>
<description> With a particular data corruption
dwarf_attrlist() failed to return an error and
the library would dereference a stale pointer.
This also provoked a memory leak.
</description>
<datefixed>2023-03-02</datefixed>
<references> regressiontests/ossfuzz56465/fuzz_die_cu_offset-5866690199289856
</references>
<gitfixid>948352178dc791796ed574a961191844d8322493</gitfixid>
<tarrelease>libdwarf-0.7.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202301-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2023-01-24</datereported>
<reportedby>Steve Kaufmann</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of Service with DW_FORM_strx3
</vulnerability>
<description> Any use of DW_FORM_strx3 or
DW_FORM_addrx3 would get libdwarf very confused
and incorrect return values
and or a library crash might result.
</description>
<datefixed>2023-01-24</datefixed>
<references> regressiontests/kaufmann2/ct-bad.o
</references>
<gitfixid>97e90eb7ab98df60b8da0bdc2ac855711c4db804</gitfixid>
<tarrelease>libdwarf-0.6.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202212-001</dwid>
<cve></cve>
<fuzzer>oss-fuzz</fuzzer>
<datereported>2022-12-28</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of Service with fuzzed object.
</vulnerability>
<description> The fuzzed testcase has at least four major
errors which libdwarf did not catch, leading
to unpredictable library behavior, possibly
including crashing the calling program.
Things not noticed before the fix (and now resulting
in error being reported):
A) The object has just 2 sections,
too few to be real. at least 3 sections are needed
to contain DWARF information of any kind.
B) Section zero has non-zero contents, in violation
of the Elf object specification.
C) The header says section strings are in section
zero (a violation of the Elf specification).
D) Section 1 masquerades as .note.gnu.debug-id
and the description size is gigantic (as is
the section, which fits the description field
length).
</description>
<datefixed>2023-01-09</datefixed>
<references> regressiontests/ossfuzz54724/clusterfuzz-54724-poc
</references>
<gitfixid>45f6d778811553a835916b60845933e6dda63b7f</gitfixid>
<tarrelease>libdwarf-0.6.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202208-001</dwid>
<cve></cve>
<fuzzer>unspecified</fuzzer>
<datereported>2022-08-27</datereported>
<reportedby>Han Zheng</reportedby>
<product>libdwarf</product>
<vulnerability> Double free on corrupted frame data.
</vulnerability>
<description> A carefully corrupted object file
would cause libdwarf to do a double free in
handling an error condition in
dwarf_expand_frame_instructions().
(in libdwarf/dwarf_frame.c)
That could cause a segmentation violation or other
major error, terminating the calling application and
resulting in Denial Of Service.
</description>
<datefixed>2022-08-27</datefixed>
<references> regressiontests/hanzheng/fuzzedobject
</references>
<gitfixid>428235e3d132fb62faf7732735fdbb034d6264b4</gitfixid>
<tarrelease>libdwarf-0.5.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202207-001</dwid>
<cve></cve>
<fuzzer>ossfuzz</fuzzer>
<datereported>2022-05-01</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> buffer overflow in dwarf_form.c
</vulnerability>
<description> A carefully corrupted string
would cause libdwarf to read outside of a buffer containing
the string (one past the end) when checking the string
to determine if it is a full path in processing
a .gnu.debuglink section.
That could cause a segmentation violation or other
major error, terminating the calling application and
resulting in Denial Of Service.
</description>
<datefixed>2022-07-23</datefixed>
<references> regressiontests/ossfuzz47150/clusterfuzz-testcase-minimized-fuzz_init_path-6727387238236160.fuzz
</references>
<gitfixid>24dff940cc4c71a9c3cb5475aee231b19163a12c</gitfixid>
<tarrelease>libdwarf-0.5.0.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202206-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2022-06-15</datereported>
<reportedby>Casper Sun</reportedby>
<product>libdwarf</product>
<vulnerability> buffer overflow in dwarf_form.c
</vulnerability>
<description> A carefully corrupted .debug_info section
would cause libdwarf to read outside of a buffer containing
a Dwarf_Sig8 symbolic reference.
That could cause a segmentation violation or other
major error, terminating the calling application and
resulting in Denial Of Service.
This failure to check for buffer overflow has been present
since DWARF4 when DW_FORM_ref_sig8 was added to libdwarf.
</description>
<datefixed>2022-06-15</datefixed>
<references> regressiontests/sleicasper2/buffer-overflow-dwarf-form
</references>
<gitfixid>7ef09e1fc9ba07653dd078edb2408631c7969162</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202205-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2022-05-26</datereported>
<reportedby>Casper Sun</reportedby>
<product>libdwarf</product>
<vulnerability> buffer overflow in dwarf_globals.c
</vulnerability>
<description> A carefully corrupted .debug_pubnames section
would cause libdwarf to read outside of a buffer containing
the section contents.
That could cause a segmentation violation or other
major error, terminating the calling application and
resulting in Denial Of Service.
The bug has been present for many years.
</description>
<datefixed>2022-05-29</datefixed>
<references> regressiontests/sleicasper/bufferoverflow
</references>
<gitfixid>8151575a6ace77d005ca5bb5d71c1bfdba3f7069</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-016</dwid>
<cve></cve>
<fuzzer>oss-fuzz-41240</fuzzer>
<datereported>2021-11-20</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_path
</vulnerability>
<description> A corrupted object.
The PE object section header for
section .gnu_debuglink is corrupted. A very
large number is in the VirtualSize field.
Attempting a malloc for the section could
succeed or might fail, resulting in
Denial Of Service.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=41240</preline>
</pre>
</description>
<datefixed>2021-11-21</datefixed>
<references> regressiontests/ ossfuzz41240/clusterfuzz-testcase-minimized-fuzz_init_path-5929343686148096
</references>
<gitfixid>a120c808234060c3c9b1872ab9a059aa1ac70b1d</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-015</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40896</fuzzer>
<datereported>2021-11-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_path
</vulnerability>
<description> A corrupted object.
Several Elf section sizes and section offsets are larger than
the file size.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40896</preline>
</pre>
</description>
<datefixed>2021-11-12</datefixed>
<references> regressiontests/ossfuzz40896/clusterfuzz-testcase-fuzz_init_path-5337872492789760
regressiontests/ossfuzz40896/clusterfuzz-testcase-minimized-fuzz_init_path-5337872492789760
</references>
<gitfixid>b7a119dc07c502c1334bcbf8dd04ca0e4d5f6ab6</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-014</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40895</fuzzer>
<datereported>2021-11-10</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_binary
</vulnerability>
<description> A corrupted object.
Some Elf section sizes are larger than the file size.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40895</preline>
</pre>
</description>
<datefixed>2021-11-12</datefixed>
<references> regressiontests/ossfuzz40895/clusterfuzz-testcase-fuzz_init_binary-4805508242997248
regressiontests/ossfuzz40895/clusterfuzz-testcase-minimized-fuzz_init_binary-4805508242997248
</references>
<gitfixid>b7a119dc07c502c1334bcbf8dd04ca0e4d5f6ab6</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-013</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40802</fuzzer>
<datereported>2021-11-07</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null-dereference READ in dwarf_object_init_b
</vulnerability>
<description> A corrupted object.
The error handling code in dwarf_object_init_b
was not properly dealing with a NULL pointer
Dwarf_Error *errp in the test code.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40802</preline>
</pre>
</description>
<datefixed>2021-11-19</datefixed>
<references> regressiontests/ossfuzz40802/ clusterfuzz-testcase-fuzz_init_binary-5538015955517440.fuzz
regressiontests/ossfuzz40802/clusterfuzz-testcase-minimized-fuzz_init_binary-5538015955517440.fuzz
</references>
<gitfixid>adf4dae25b39039f1821b095688c00f3010e1d37</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-012</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40801</fuzzer>
<datereported>2021-11-07</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Timeout in fuzz_init_path
</vulnerability>
<description> A corrupted object. libdwarf detects it quickly now.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40801</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz801/clusterfuzz-testcase-fuzz_init_path-5443517279764480
regressiontests/ossfuzz40801/clusterfuzz-testcase-minimized-fuzz_init_path-5443517279764480
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-011</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40799</fuzzer>
<datereported>2021-11-02</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_path
</vulnerability>
<description> A corrupted object.
Gigantic section sizes or offsets were provoking
a large malloc. Now these are detected and
no malloc is attempted (an error is returned).
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40799</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz40799/clusterfuzz-testcase-fuzz_init_path-5245778948390912
regressiontests/ossfuzz40799/clusterfuzz-testcase-minimized-fuzz_init_path-5245778948390912
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-010</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40627</fuzzer>
<datereported>2021-11-02</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Abrt in _dwarf_error_string
</vulnerability>
<description> The Elf object file has some corruption. The
read now stops with an error.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40627</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz40627/clusterfuzz-testcase-fuzz_init_path-5186858573758464
regressiontests/ossfuzz40627/clusterfuzz-testcase-minimized-fuzz_init_path-5186858573758464
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-009</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40729</fuzzer>
<datereported>2021-11-05</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Timeout - fuzz_init_binary
</vulnerability>
<description> The object file (macho 64 bit) has some
header fuzzing that was not caught reading
the object until the macho reader
tried a gigantic malloc..
Now the library code catches the error before malloc and
returns an error code.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40729</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz40729/clusterfuzz-testcase-minimized-fuzz_init_binary-4791627277795328
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-008</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40731</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_binary
</vulnerability>
<description> The fuzzed macho64 object has corrupted
headers. The library notices and reports an error.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40731</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz40731/clusterfuzz-testcase-fuzz_init_binary-5983147574034432
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-005</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40674</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Heap-buffer-overflow in _dwarf_elf_setup_all_section_groups
</vulnerability>
<description> Object file has corrupt section group information.
Results in buffer overflow.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40674#c6</preline>
</pre>
</description>
<datefixed>2021-11-07</datefixed>
<references> regressiontests/ossfuzz40674/clusterfuzz-testcase-minimized-fuzz_init_path-6557751518560256
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-004</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40673</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Null-dereference READ in dwarf_object_init_b
</vulnerability>
<description> The macho object has corrupted headers
and now mentions that and stops.
Verified as fixed by oss-fuzz 2021-11-03
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40673</preline>
</pre>
</description>
<datefixed>2021-11-05</datefixed>
<references> regressiontests/ossfuzz40673/clusterfuzz-testcase-minimized-fuzz_init_path-6240961391362048.fuzz
</references>
<gitfixid>94dece3ce0f030d06da442a103bd6a5301410b25</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-003</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40671</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Direct-leak in _dwarf_get_debug
</vulnerability>
<description> The test code is calling a libdwarf-internal
function (which is against the rules, only libdwarf
function names beginning with dwarf_ are callable.
When building libdwarf as an archive there is no
means to enforce this rule)
doc/libdwarf.mm/pdf now documents this rule.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40671</preline>
</pre>
</description>
<datefixed>2021-11-05</datefixed>
<references> regressiontests/oss40671/clusterfuzz-testcase-fuzz_init_path-5455557297831936
regressiontests/oss40671/clusterfuzz-testcase-minimized-fuzz_init_path-5455557297831936
</references>
<gitfixid>b40f7e291216e771185f62292dd6304b5a662926</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-002</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40669</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-memory in fuzz_init_path
</vulnerability>
<description> Corrupted MachO object can crash caller.b
Two fields in the MachO file header
were not checked for sanity so nonsense large values
could lead to excessive malloc and or a caller
segmentation violation. Fixed by DW202111-001.
Verified as fixed by oss-fuzz
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40669</preline>
</pre>
</description>
<datefixed>2021-11-04</datefixed>
<references> regressiontests/ossfuzz40669/clusterfuzz-testcase-minimized-fuzz_init_path-5399726397194240
regressiontests/clusterfuzz-testcase-fuzz_init_path-5399726397194240
</references>
<gitfixid>b40f7e291216e771185f62292dd6304b5a662926</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202111-001</dwid>
<cve></cve>
<fuzzer>oss-fuzz-40663</fuzzer>
<datereported>2021-11-03</datereported>
<reportedby>David Korczynski</reportedby>
<product>libdwarf</product>
<vulnerability> Timeout in fuzz_init_path
</vulnerability>
<description> Corrupted MachO object can crash caller
Two fields in the MachO file header
were not checked for sanity so nonsense large values
could lead to excessive malloc and or a caller
segmentation violation.
Verified by oss-fuzz as fixed.
The testcase has illegal libdwarf call
and improper include statements.
<pre>
<preline> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40663</preline>
</pre>
</description>
<datefixed>2021-11-04</datefixed>
<references> regressiontests/ossfuzz40663/clusterfuzz-testcase-minimized-fuzz_init_path-6122542432124928
</references>
<gitfixid>b40f7e291216e771185f62292dd6304b5a662926</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202010-003</dwid>
<cve>CVE-2020-28163</cve>
<fuzzer></fuzzer>
<datereported>2020-10-27</datereported>
<reportedby>Casper Sun</reportedby>
<product>libdwarf</product>
<vulnerability> Passing null to %s due to corrupt line table header.
</vulnerability>
<description> If a DWARF5 line table header has an invalid
FORM for a pathname, the fi_file_name field may be null
and printing it via %s can result in referencing memory
at address 0, possibly generating segmentation
violation or application crash. Now in case of null
we provide a fixed string of <no file name>
and for the form code we print the value and <unknown form>
so there are no unpredictable effects.
<pre>
<preline> This should be visible after redhat makes it public.</preline>
<preline> Filed on bugzilla.redhat 23 November 2021.</preline>
<preline> bugzilla.redhat.com/show_bug.cgi?id=2026000</preline>
</pre>
</description>
<datefixed>2020-10-28</datefixed>
<references> regressiontests/c-sun2/nullpointer
</references>
<gitfixid>faf99408e3f9f706fc3809dd400e831f989778d3</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202010-002</dwid>
<cve>CVE-2020-28162</cve>
<fuzzer></fuzzer>
<datereported>2020-10-27</datereported>
<reportedby>Casper Sun</reportedby>
<product>dwarfdump</product>
<vulnerability> dwarfdump crashes if the nest of C scopes is too deep
</vulnerability>
<description> An object file where the DIEs depth of
nesting exceeds the limit of 800 levels
due to corruption or a compiler bug
can result in exhausting the die stack array and
writing past its end.
A segmentation fault is possible.
The code at the point of error was not adjusting
the array index properly
so an invalid dereference could occur.
Now the test code is correct and the array overflow
is detected resulting in a normal error return.
Additional places where this could occur were
identified and the proper test added.
<pre>
<preline> Unable to enter in bugzilla.redhat.com</preline>
<preline> so CVE can be completed by Fedora (as CNA)</preline>
<preline> as dwarfdump is not part of Fedora</preline>
</pre>
</description>
<datefixed>2020-10-28</datefixed>
<references> regressiontests/c-sun2/globaloverflow
</references>
<gitfixid>a7fa8edd640b74daf8e7a442dcec96640875b4fb</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW202010-001</dwid>
<cve>CVE-2020-27545</cve>
<fuzzer></fuzzer>
<datereported>2020-10-10</datereported>
<reportedby>Casper Sun</reportedby>
<product>libdwarf</product>
<vulnerability> A carefully corrupted line table can crash calling app
</vulnerability>
<description> A carefully crafted object with an
invalid line table could cause libdwarf
to dereference a pointer reading a single byte outside of
the intended .debug_line section and potentially
outside of memory visible to the library.
A segmentation fault is possible.
The code testing for the error was coded incorrectly
so an invalid dereference could occur.
Now the test code is correct and the error
is detected resulting in a normal error return.
<pre>
<preline> This should be visible after redhat makes it public.</preline>
<preline> Filed on bugzilla.redhat 22 November 2021.</preline>
<preline> bugzilla.redhat.com/show_bug.cgi?id=2025694</preline>
</pre>
</description>
<datefixed>2020-10-17</datefixed>
<references> regressiontests/c-sun/poc
</references>
<gitfixid>95f634808c01f1c61bbec56ed2395af997f397ea</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201907-001</dwid>
<cve>CVE-2019-14249</cve>
<fuzzer></fuzzer>
<datereported>2019-07-23</datereported>
<reportedby>unknown</reportedby>
<product>libdwarf</product>
<vulnerability> Denial of service with zero size section group
</vulnerability>
<description> dwarf_elf_load_headers.c in libdwarf before 2019-07-05 allows attackers to cause a denial of service (division by zero) via an ELF file with a zero-size section group (SHT_GROUP), as demonstrated by dwarfdump.
</description>
<datefixed>2019-07-05</datefixed>
<references></references>
<gitfixid>cb7198abde46c2ae29957ad460da6886eaa606ba</gitfixid>
<tarrelease>libdwarf-0.4.1.tar.xz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201801-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2018-01-28</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>dwarfdump</product>
<vulnerability> Incorrect frame section can crash dwarfdump
</vulnerability>
<description> A carefully crafted object with an
invalid frame section set of initial-instructions
can crash the frame-instructions decode in
dwarfdump. In addition, a couple places in libdwarf
are not as careful in checking frame data as
they should be.
A segmentation-fault/core-dump is possible.
</description>
<datefixed>2018-01-29</datefixed>
<references> sarubbo-11/testcase{1,2,3,4,5}.bin
</references>
<gitfixid>7af0ecddfafed88446969cbf8c888356ad485d99</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201712-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-12-01</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Incorrect frame section could let caller crash
</vulnerability>
<description> A carefully crafted object with an
invalid frame section
can result in passing back data to a caller of
dwarf_get_fde_augmentation_data()
is erroneous and will result in the
caller reference off the end of the frame
section.
A segmentation-fault/core-dump is possible.
</description>
<datefixed>2017-12-01</datefixed>
<references> sarubbo-10/1.crashes.bin
</references>
<gitfixid>329ea8e56bc9550260cae6e2e9756bfbe7e2ff6d</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201711-002</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-11-08</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Incorrect line table section could crash caller
</vulnerability>
<description> An carefully crafted object with a
invalid line table section crafted to
end early at a particular point resulted in
dereferencing outside the line table from
libdwarf/dwarf_line_table_reader_common.c .
A segmentation-fault/core-dump is possible.
</description>
<datefixed>2017-11-08</datefixed>
<references> regressiontests/sarubbo-9/3.crashes.bin
</references>
<gitfixid>a1644f4dde7dd5990537ff7ad22a9e94b8723186</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201711-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-11-01</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Incorrect frame section could crash caller
</vulnerability>
<description> A carefully crafted object with a
resulting invalid frame section
with DW_CFA_advance_loc1 implying
data off-the-end-of-section
will dereference an invalid pointer.
A segmentation fault and core dump is possible.
Corrected code checks now.
</description>
<datefixed>2017-11-02</datefixed>
<references> regressiontests/sarubbo-8/1.crashes.bin
</references>
<gitfixid>44349d7991e44dd3751794f76537cabcf65ee28d</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201709-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-09-19</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Incorrect abbrev section could crash caller.
</vulnerability>
<description> A fuzzed object with a
resulting invalid abbrev section where
the end of section follows an abbrev tag
would dereference a non-existent has-child byte.
</description>
<datefixed>2017-09-26</datefixed>
<references> regressiontests/sarubbo-3/1.crashes.bin
</references>
<gitfixid>bcc2e33908e669bacd397e3c941ffd1db3005d17</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201706-001</dwid>
<cve>CVE-2017-9998</cve>
<fuzzer></fuzzer>
<datereported>2017-06-28</datereported>
<reportedby>team OWL337</reportedby>
<product>libdwarf</product>
<vulnerability> Addition overflow in libdwarf leads to segmentation violation
</vulnerability>
<description> A fuzzed object with a
resulting invalid value can overflow
when added to a valid pointer
(depending on how the runtime memory is laid out)
and thereafter a dereference results in a
segmentation violation).
<pre> see
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1465756</preline>
<preline> for contact information of those finding the bug.</preline>
<preline> Fabian Wolff sent email and provided</preline>
<preline> the link to the web page.</preline>
</pre>
</description>
<datefixed>2017-07-06</datefixed>
<references> regressiontests/wolff/POC1
</references>
<gitfixid>e91681e8841291f57386f26a90897fd1dcf92a6e</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-007</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf (libelf)</product>
<vulnerability> Heap overflow in strncmp (libelf bug)
</vulnerability>
<description> 7/7. A heap overflow in
strncmp() is due to libelf failing to check arguments
to elf_ strptr.
This is not a bug in libdwarf, it is a libelf bug.
A pointer for being in bounds (in a few places in this
function) and a failure in a check in dwarf_attr_list().
The test object is intentionally corrupted (fuzzed).
<pre>
<preline> A portion of sanitizer output with Ubuntu 14.04:</preline>
<preline> ==180133==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x60d00000cff1 at pc 0x0000004476f4</preline>
<preline> bp 0x7fff87dd7dd0 sp 0x7fff87dd7590</preline>
<preline> READ of size 8 at 0x60d00000cff1 thread T0</preline>
<preline> #0 0x4476f3 in __interceptor_strncmp (/home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/dwarfdump/dwarfdump+0x4476f3)</preline>
<preline> #1 0x7992ae in this_section_dwarf_relevant /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/dwarf_init_finish.c:608:13</preline>
<preline> #2 0x781064 in _dwarf_setup /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/dwarf_init_finish.c:722:14</preline>
<preline> #3 0x77d59c in dwarf_object_init /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/dwarf_init_finish.c:922:20</preline>
<preline> With Ubuntu 16.04 libelf dwarfdump gets:</preline>
<preline> ERROR: dwarf_elf_init: DW_DLE_ELF_STRPTR_ERROR (30)</preline>
<preline> a call to elf_strptr() failed trying to get a section name</preline>
</pre>
Fix date is irrelevant, libdwarf no longer uses libelf.
</description>
<datefixed>2017-07-06</datefixed>
<references> regressiontests/marcel/crash7
</references>
<gitfixid>cc37d6917011733d776ae228af4e5d6abe9613c1</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-006</dwid>
<cve>CVE-2017-9052</cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf</product>
<vulnerability> Heap overflow in dwarf_formsdata
</vulnerability>
<description> 6/7. A heap overflow in
dwarf_formsdata() is due to a failure to check
a pointer for being in bounds (in a few places in this
function) and a failure in a check in dwarf_attr_list().
The test object is intentionally corrupted (fuzzed).
<pre>
<preline> A portion of sanitizer output with Ubuntu 14.04:</preline>
<preline> ==180130==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x61100000589c at pc 0x0000006cab95</preline>
<preline> bp 0x7fff749aab10 sp 0x7fff749aab08</preline>
<preline> READ of size 1 at 0x61100000589c thread T0</preline>
<preline> #0 0x6cab94 in dwarf_formsdata /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/dwarf_form.c:937:9</preline>
<preline> #1 0x567daf in get_small_encoding_integer_and_name /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/dwarfdump/print_die.c:1533:16</preline>
<preline> #2 0x562f28 in get_attr_value /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/dwarfdump/print_die.c:5030:24</preline>
<preline> #3 0x555f86 in print_attribute /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/dwarfdump/print_die.c:3357:13</preline>
<preline> After fixes applied dwarfdump says:</preline>
<preline> ERROR: dwarf_attrlist: DW_DLE_DW_DLE_ATTR_OUTSIDE_SECTION(281)</preline>
</pre>
</description>
<datefixed>2017-03-21</datefixed>
<references> regressiontests/marcel/crash6
</references>
<gitfixid>cc37d6917011733d776ae228af4e5d6abe9613c1</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-005</dwid>
<cve>CVE-2017-9053</cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf</product>
<vulnerability> Heap overflow in _dwarf_read_loc_expr_op()
</vulnerability>
<description> 5/7. A heap overflow in
_dwarf_read_loc_expr_op() is due to a failure to check
a pointer for being in bounds (in a few places in this
function).
The test object is intentionally corrupted (fuzzed).
<pre>
<preline> A portion of sanitizer output with Ubuntu 14.04:</preline>
<preline> ==180112==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x60800000bf72 at pc 0x00000084dd52</preline>
<preline> bp 0x7ffc12136fd0 sp 0x7ffc12136fc8</preline>
<preline> READ of size 1 at 0x60800000bf72 thread T0</preline>
<preline> #0 0x84dd51 in _dwarf_read_loc_expr_op /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/./dwarf_loc.c:250:9</preline>
<preline> #1 0x841f16 in _dwarf_get_locdesc_c /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/./dwarf_loc2.c:109:15</preline>
<preline> #2 0x837d08 in dwarf_get_loclist_c /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/./dwarf_loc2.c:685:18</preline>
<preline> #3 0x57dff2 in get_location_list /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/dwarfdump/print_die.c:3812:16</preline>
<preline> After fixes applied dwarfdump says:</preline>
<preline> ERROR: dwarf_get_loclist_c: DW_DLE_LOCEXPR_OFF_SECTION_END</preline>
<preline> (343) Corrupt dwarf</preline>
</pre>
</description>
<datefixed>2017-03-21</datefixed>
<references> regressiontests/marcel/crash5
</references>
<gitfixid>cc37d6917011733d776ae228af4e5d6abe9613c1</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-004</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf (libelf)</product>
<vulnerability> Heap overflow in set_up_section strlen
</vulnerability>
<description> 4/7. An apparent heap overflow that
gives the appearance of being in libdwarf is due to
libelf call elf_strptr() failing to fully check
that its arguments make sense.
This is not a bug in libdwarf, it is a libelf bug.
The test object is intentionally corrupted (fuzzed).
The submission was with Ubuntu 14.04. With Ubuntu
16.04 there is no sanitizer error report.
As of 2023 libdwarf no longer calls or references libelf.
<pre>
<preline> A portion of sanitizer output with Ubuntu 14.04:</preline>
<preline> ==180109==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x60b00000b000 at pc 0x00000048fd12</preline>
<preline> bp 0x7fff4ad31ef0 sp 0x7fff4ad316b0</preline>
<preline> READ of size 16 at 0x60b00000b000 thread T0</preline>
<preline> #0 0x48fd11 in __interceptor_strlen (/home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/dwarfdump+0x48fd11)</preline>
<preline> #1 0x7a84a4 in set_up_section /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:285:27</preline>
<preline> #2 0x79aaa5 in enter_section_in_de_debug_sections_array /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:355:5</preline>
<preline> #3 0x78170b in _dwarf_setup /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:746:19</preline>
<preline> With Ubuntu 16.04 libelf one gets:</preline>
<preline> ERROR: dwarf_elf_init: DW_DLE_ELF_STRPTR_ERROR (30)</preline>
<preline> a call to elf_strptr() failed trying to get a section name</preline>
</pre>
</description>
<datefixed></datefixed>
<references> regressiontests/marcel/crash4
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-003</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf (libelf)</product>
<vulnerability> Heap overflow in strcmp
</vulnerability>
<description> 3/7. An apparent heap overflow that
gives the appearance of being in libdwarf is due to
libelf call elf_strptr() failing to fully check
that its arguments make sense.
This is not a bug in libdwarf, it is a libelf bug.
The test object is intentionally corrupted (fuzzed).
The submission was with Ubuntu 14.04. With Ubuntu
16.04 there is no sanitizer error report.
A portion of sanitizer output with Ubuntu 14.04:
<pre>
<preline> ==180106==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x60f00000ef09 at pc 0x000000447300</preline>
<preline> bp 0x7ffc667dce10 sp 0x7ffc667dc5d0</preline>
<preline> READ of size 4 at 0x60f00000ef09 thread T0</preline>
<preline> #0 0x4472ff in __interceptor_strcmp (/home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/dwarfdump+0x4472ff)</preline>
<preline> #1 0x79938f in this_section_dwarf_relevant /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:612:12</preline>
<preline> #2 0x781064 in _dwarf_setup /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:722:14</preline>
<preline> #3 0x77d59c in dwarf_object_init /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_init_finish.c:922:20</preline>
<preline> #4 0x899d4f in dwarf_elf_init_file_ownership /</preline>
</pre>
With Ubuntu 16.04 libelf one gets:
ERROR: dwarf_elf_init: DW_DLE_ELF_STRPTR_ERROR (30)
a call to elf_strptr() failed trying to get a section name
Fix date is irrelevant, libdwarf no longer uses libelf.
</description>
<datefixed></datefixed>
<references> regressiontests/marcel/crash3
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-002</dwid>
<cve>CVE-2017-9054</cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf</product>
<vulnerability> Heap overflow in _dwarf_decode_s_leb128_chk()
</vulnerability>
<description> 2/7. In _dwarf_decode_s_leb128_chk()
a byte pointer was dereferenced just before was checked
as being in bounds.
The test object is intentionally corrupted (fuzzed).
<pre>
<preline> A portion of sanitizer output:</preline>
<preline> .debug_line: line number info for a single cu</preline>
<preline> ==180103==ERROR: AddressSanitizer: heap-buffer-overflow</preline>
<preline> on address 0x610000007ffc at pc 0x0000007b0f5b</preline>
<preline> bp 0x7ffe06bbf510 sp 0x7ffe06bbf508</preline>
<preline> READ of size 1 at 0x610000007ffc thread T0</preline>
<preline> #0 0x7b0f5a in _dwarf_decode_s_leb128_chk /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/dwarf_leb.c:304:9</preline>
<preline> #1 0x7e753e in read_line_table_program /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/./</preline>
<preline> dwarf_line_table_reader_common.c:1167:17</preline>
<preline> #2 0x7d7fe3 in _dwarf_internal_srclines /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/./dwarf_line.c:690:15</preline>
<preline> #3 0x7f9dbb in dwarf_srclines_b /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/libdwarf/./dwarf_line.c:944:12</preline>
<preline> #4 0x5caaa5 in print_line_numbers_this_cu /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/print_lines.c:762:16</preline>
<preline> After fix applied one gets:</preline>
<preline> ERROR: dwarf_srclines: DW_DLE_LEB_IMPROPER (329)</preline>
<preline> Runs off end of section or CU</preline>
</pre>
</description>
<datefixed>2017-03-21</datefixed>
<references> regressiontests/marcel/crash2
</references>
<gitfixid>cc37d6917011733d776ae228af4e5d6abe9613c1</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201703-001</dwid>
<cve>CVE-2017-9055</cve>
<fuzzer></fuzzer>
<datereported>2017-03-21</datereported>
<reportedby>Marcel Bohme and Van-Thuan Pham</reportedby>
<product>libdwarf</product>
<vulnerability> Heap overflow in dwarf_formsdata
</vulnerability>
<description> 1/7. In dwarf_formsdata() a few
data types were not checked as being in bounds.
The test object is intentionally corrupted (fuzzed).
<pre>
<preline> A portion of sanitizer output:</preline>
<preline> LOCAL_SYMBOLS:</preline>
<preline> < 1><0x0000002f> DW_TAG_subprogram</preline>
<preline> ==180088==ERROR: AddressSanitizer: heap-buffer-overflow on</preline>
<preline> address 0x60800000bf72 at pc 0x0000006cab95 bp</preline>
<preline> 0x7fff31425830 sp 0x7fff31425828</preline>
<preline> READ of size 1 at 0x60800000bf72 thread T0</preline>
<preline> #0 0x6cab94 in dwarf_formsdata /home/ubuntu/subjects/</preline>
<preline> build-asan/libdwarf/libdwarf/dwarf_form.c:937:9</preline>
<preline> #1 0x567daf in get_small_encoding_integer_and_name /home/</preline>
<preline> ubuntu/subjects/build-asan/libdwarf/dwarfdump/print_die.c:1533:16</preline>
<preline> #2 0x576f38 in check_for_type_unsigned /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/print_die.c:4301:11</preline>
<preline> #3 0x56ad8c in formxdata_print_value /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/print_die.c:4374:39</preline>
<preline> #4 0x5643be in get_attr_value /home/ubuntu/</preline>
<preline> subjects/build-asan/libdwarf/dwarfdump/print_die.c:5140:24</preline>
<preline> #5 0x555f86 in print_attribute /home/ubuntu/subjects/build</preline>
<preline> ...</preline>
<preline> After fixes applied dwarfdump gets:</preline>
<preline> ERROR: dwarf_attrlist: DW_DLE_DW_DLE_ATTR_OUTSIDE_SECTION(281)</preline>
</pre>
</description>
<datefixed>2017-03-21</datefixed>
<references> regressiontests/marcel/crash1
</references>
<gitfixid>cc37d6917011733d776ae228af4e5d6abe9613c1</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-008</dwid>
<cve>CVE-2016-10254</cve>
<fuzzer></fuzzer>
<datereported>2016-11-04</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Crash libelf reading fuzzed object.
</vulnerability>
<description> This is a weakness in libelf checking.
Testing that current libdwarf deals with it properly,
though it was never a bug in libdwarf.
The CVE mentions libdwarf.
<pre>
<preline> blogs.gentoo.org/ago/2016/11/04/elfutils-memory-allocation-failure-in-allocate_elf-common-h/</preline>
<preline> www.openwall.com/lists/oss-security/2017/03/22/2</preline>
</pre>
Fixed in gentoo libelf by Agostino Sarubbo.
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-b/00011-elfutils-memalloc-allocate_elf
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-007</dwid>
<cve>CVE-2016-10255</cve>
<fuzzer></fuzzer>
<datereported>2016-11-04</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Crash libelf reading fuzzed object.
</vulnerability>
<description> This is a weakness in libelf checking.
Testing that current libdwarf deals with it properly,
though it was never a bug in libdwarf.
The CVE mentions libdwarf.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1387584</preline>
<preline> www.openwall.com/lists/oss-security/2017/03/22/1</preline>
<preline> blogs.gentoo.org/ago/2016/11/04/elfutils-memory-allocation-failure-in-__libelf_set_rawdata_wrlock-elf_getdata-c/</preline>
</pre>
Fixed in gentoo libelf by Agostino Sarubbo.
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-a/00031-elfutils-memalloc-__libelf_set_rawdata_wrlock
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-006</dwid>
<cve>CVE-2016-9480</cve>
<fuzzer></fuzzer>
<datereported>2016-11-14</datereported>
<reportedby>Puzzor (Shi Ji)</reportedby>
<product>libdwarf</product>
<vulnerability> Heap buffer overflow
</vulnerability>
<description> An object with corrupt contents causes a memory reference
out of bounds, a heap buffer overflow reference.
<pre>
<preline> heap-buffer-overflow in dwarf_util.c:208 for val_ptr</preline>
<preline> # Version</preline>
<preline> bb9a3492ac5713bed9cf3ae58ddb7afa6e9e98f8</preline>
<preline> (in regression tests here named heap_buf_overflow.o)</preline>
<preline> # ASAN Output</preline>
<preline> <0> tag: 17 DW_TAG_compile_unit name: "strstrnocase.c" FORM 0xe "DW_FORM_strp"</preline>
<preline> <1> tag: 46 DW_TAG_subprogram name: "is_strstrnocase" FORM 0xe "DW_FORM_strp"</preline>
<preline> =================</preline>
<preline> ==1666==ERROR: AddressSanitizer: heap-buffer-overflow on address</preline>
<preline> 0xb5846db9 at p</preline>
<preline> c 0x080b3a1b bp 0xbfa75d18 sp 0xbfa75d08</preline>
<preline> READ of size 1 at 0xb5846db9 thread T0</preline>
<preline> #0 0x80b3a1a in _dwarf_get_size_of_val /home/puzzor/libdwarf-code/</preline>
<preline> libdwarf/dwarf_util.c:208</preline>
<preline> #1 0x8056602 in _dwarf_next_die_info_ptr /home/puzzor/libdwarf-code/</preline>
<preline> libdwarf/dwarf_die_deliv.c:1353</preline>
<preline> #2 0x8057f4b in dwarf_child /home/puzzor/libdwarf-code/libdwarf/</preline>
<preline> dwarf_die_de liv.c:1688</preline>
<preline> #3 0x804b5fa in get_die_and_siblings simplereader.c:637</preline>
<preline> #4 0x804b65c in get_die_and_siblings simplereader.c:643</preline>
<preline> #5 0x804b3f3 in read_cu_list simplereader.c:611</preline>
<preline> #6 0x804aeae in main simplereader.c:533</preline>
<preline> #7 0xb6ffe275 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18275)</preline>
<preline> #8 0x80491c0 (/home/puzzor/libdwarf-code/dwarfexample/simplereader+</preline>
<preline> 0x80491c 0)</preline>
<preline> 0xb5846db9 is located 0 bytes to the right of 249-byte region</preline>
<preline> [0xb5846cc0,0xb5846db9)</preline>
<preline> allocated by thread T0 here:</preline>
<preline> #0 0xb727fae4 in __interceptor_malloc (/usr/lib/i386-linux-gnu/libasan.so.</preline>
<preline> 3+ 0xc3ae4)</preline>
<preline> #1 0xb71a9b98 (/usr/lib/i386-linux-gnu/libelf.so.1+0x9b98)</preline>
</pre>
For the orignal bug report see
<pre>
<preline> https://sourceforge.net/p/libdwarf/bugs/5/</preline>
</pre>
</description>
<datefixed>2016-11-16</datefixed>
<references> regressiontests/puzzor/heap_buf_overflow.o
</references>
<gitfixid>5dd64de047cd5ec479fb11fe7ff2692fd819e5e5</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-005</dwid>
<cve>CVE-2016-9558</cve>
<fuzzer></fuzzer>
<datereported>2016-11-11</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> negation of -9223372036854775808 cannot be represented in type
</vulnerability>
<description> With the right bit pattern in a signed leb number
the signed leb decode would execute an unary minus with undefined
effect. This is not known to generate an incorrect value,
but it could, one supposes.
</description>
<datefixed>2016-11-11</datefixed>
<references> regressiontests/sarubbo-2/00050-libdwarf-negate-itself
</references>
<gitfixid>4f19e1050cd8e9ddf2cb6caa061ff2fec4c9b5f9</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-004</dwid>
<cve>CVE-2016-9275</cve>
<fuzzer></fuzzer>
<datereported>2016-11-02</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Heap overflow in dwarf_skim_forms()
</vulnerability>
<description> If a non-terminated string
in a DWARF5 macro section
ends a section it can result in accessing memory not
in the application (out of bounds read).
dwarf_macro5.c(in _dwarf_skim_forms()).
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-2/00027-libdwarf-heapoverflow-_dwarf_skim_forms
</references>
<gitfixid>583f8834083b5ef834c497f5b47797e16101a9a6</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-003</dwid>
<cve>CVE-2016-9276</cve>
<fuzzer></fuzzer>
<datereported>2016-11-02</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Bad aranges length leads to overflow and bad pointer
</vulnerability>
<description> in dwarf_arange.c(dwarf_get_aranges_list) an aranges
header with corrupt data could, with an overflowing calculation,
result in pointers to invalid or inappropriate memory being
dereferenced.
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-2/00026-libdwarf-heapoverflow-dwarf_get_aranges_list
</references>
<gitfixid>583f8834083b5ef834c497f5b47797e16101a9a6</gitfixid>
<tarrelease>libdwarf-20180129.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-002</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2016-11-02</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> heap overflow in get_attr_value
</vulnerability>
<description> Libdwarf failed to check for a bogus
length in dwarf_form.c (dwarf_formblock()) resulting
in a pointer pointing outside of the intended memory
region. Anything could happen in the subsequent
use of the bogus pointer.
<pre>
<preline> 0x61300000de1c is located 0 bytes to the right of 348-byte region</preline>
<preline> [0x61300000dcc0,0x61300000de1c)</preline>
<preline> allocated by thread T0 here:</preline>
<preline> #0 0x4c0ad8 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-</preline>
<preline> r2/work/llvm-3.8.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52</preline>
<preline> #1 0x7f883cfc6206 in __libelf_set_rawdata_wrlock /tmp/portage/dev-</preline>
<preline> libs/elfutils-0.166/work/elfutils-0.166/libelf/elf_getdata.c:318</preline>
</pre>
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-2/00025-libdwarf-heapoverflow-get_attr_value
</references>
<gitfixid>583f8834083b5ef834c497f5b47797e16101a9a6</gitfixid>
<tarrelease>libdwarf-20170416.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201611-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2016-11-02</datereported>
<reportedby>Agostino Sarubbo</reportedby>
<product>libdwarf</product>
<vulnerability> Memory allocation failure in do_decompress_zlib
</vulnerability>
<description> In decompressing a zlib compressed section if
the decompressed section size is nonsense (too large)
an attempted malloc will fail and could let an exception
propagate to callers.
<pre>
<preline> ==27994==WARNING: AddressSanitizer failed to allocate 0x62696c2f7273752f</preline>
<preline> bytes ==27994==AddressSanitizer's allocator is terminating the process</preline>
<preline> instead of returning 0</preline>
<preline> ...</preline>
<preline> #6 0x4c0ab1 in malloc /var/tmp/portage/sys-devel/llvm-3.8.1-</preline>
<preline> #8 0x5b582e in _dwarf_load_section</preline>
<preline> #9 0x5bb479 in dwarf_srcfiles</preline>
<preline> #10 0x5145cd in print_one_die_section</preline>
</pre>
</description>
<datefixed>2016-11-04</datefixed>
<references> regressiontests/sarubbo-2/00024-libdwarf-memalloc-do_decompress_zlib
</references>
<gitfixid>583f8834083b5ef834c497f5b47797e16101a9a6</gitfixid>
<tarrelease>libdwarf-20170416.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201610-003</dwid>
<cve>CVE-2016-8679</cve>
<fuzzer></fuzzer>
<datereported>2016-10-02</datereported>
<reportedby>agostino</reportedby>
<product>libdwarf</product>
<vulnerability> dwarf_get_size_of_val out of bounds read
</vulnerability>
<description> The _dwarf_get_size_of_val function in
libdwarf/dwarf_util.c in Libdwarf before 20161124
allows remote attackers to cause a denial of service
(out-of-bounds read) by calling the dwarfdump command
on a crafted file.
<pre>
<preline> www.securityfocus.com/bid/93601</preline>
<preline> blogs.gentoo.org/ago/2016/10/06/libdwarf-heap-based-</preline>
<preline> buffer-overflow-in-_dwarf_get_size_of_val-dwarf_util-c/</preline>
</pre>
</description>
<datefixed>2016-10-04</datefixed>
<references></references>
<gitfixid>efe48cad0693d6994d9a7b561e1c3833b073a624</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW201610-002</dwid>
<cve>CVE-2016-8680</cve>
<fuzzer></fuzzer>
<datereported>2016-10-02</datereported>
<reportedby>agostino</reportedby>
<product>libdwarf</product>
<vulnerability> Out of bounds read
</vulnerability>
<description> The _dwarf_get_abbrev_for_code function in
dwarf_util.c in libdwarf 20161001 and earlier allows remote
attackers to cause a denial of service (out-of-bounds read)
by calling the dwarfdump command on a crafted file.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1385690</preline>
<preline> www.securityfocus.com/bid/93592</preline>
<preline> Duplicate of CVE-2016-8681</preline>
</pre>
</description>
<datefixed>2016-10-04</datefixed>
<references></references>
<gitfixid>efe48cad0693d6994d9a7b561e1c3833b073a624</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW201610-001</dwid>
<cve>CVE-2016-8681</cve>
<fuzzer></fuzzer>
<datereported>2016-10-02</datereported>
<reportedby>agostino</reportedby>
<product>libdwarf</product>
<vulnerability> Out of bounds read
</vulnerability>
<description> The _dwarf_get_abbrev_for_code function in
dwarf_util.c in libdwarf 20161001 and earlier allows remote
attackers to cause a denial of service (out-of-bounds read)
by calling the dwarfdump command on a crafted file.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1385690</preline>
<preline> www.securityfocus.com/bid/93592</preline>
<preline> Duplicate of CVE-2016-8680</preline>
</pre>
</description>
<datefixed>2016-10-04</datefixed>
<references></references>
<gitfixid>efe48cad0693d6994d9a7b561e1c3833b073a624</gitfixid>
<tarrelease></tarrelease>
</dwbug>
<dwbug>
<dwid>DW201609-004</dwid>
<cve>CVE-2016-7510</cve>
<fuzzer></fuzzer>
<datereported>2016-09-17</datereported>
<reportedby>Puzzor</reportedby>
<product>libdwarf</product>
<vulnerability> libdwarf 20160613 Out-of-Bounds read
</vulnerability>
<description> read line table program Out-of-Bounds read
line_ptr in dwarf_line_table_reader_common.c:1433 Out-of-Bounds read
See:
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1377015</preline>
<preline> https://sourceforge.net/p/libdwarf/bugs/4/</preline>
</pre>
<pre>
<preline> # Address Sanitizer Output</preline>
<preline> ==27763==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf4603f84 at pc 0x8408ede bp 0xffff6518 sp 0xffff6510</preline>
<preline> READ of size 1 at 0xf4603f84 thread T0</preline>
<preline> #0 0x8408edd in read_line_table_program /home/puzzor/test-fuzzing/code/libdwarf/./dwarf_line_table_reader_common.c:1433</preline>
<preline> #1 0x83f716c in _dwarf_internal_srclines /home/puzzor/test-fuzzing/code/libdwarf/./dwarf_line.c:690</preline>
<preline> #2 0x841436c in dwarf_srclines_b /home/puzzor/test-fuzzing/code/libdwarf/./dwarf_line.c:944</preline>
<preline> #3 0x81fbc28 in print_line_numbers_this_cu /home/puzzor/test-fuzzing/code/dwarfdump/print_lines.c:763</preline>
<preline> #4 0x815c191 in print_one_die_section /home/puzzor/test-fuzzing/code/dwarfdump/print_die.c:850</preline>
<preline> #5 0x81565c1 in print_infos /home/puzzor/test-fuzzing/code/dwarfdump</preline>
</pre>
</description>
<datefixed>2016-09-23</datefixed>
<references> regressiontests/DW201609-004/poc
</references>
<gitfixid>3767305debcba8bd7e1c483ae48c509d25399252</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201609-003</dwid>
<cve>CVE-2016-7410</cve>
<fuzzer></fuzzer>
<datereported>2016-09-13</datereported>
<reportedby>https://marc.info/?l=oss-security&m=147391785920048&w=2</reportedby>
<product>libdwarf</product>
<vulnerability> libdwarf 20160613 heap-buffer-overflow
</vulnerability>
<description> With AddressSanitizer,
we found a Heap-Buffer-overflow in the latest
release version of dwarfdump. The crash output is as follows:
<pre>
<preline> See also:</preline>
<preline> https://marc.info/?l=oss-security&m=147378394815872&w=2</preline>
<preline> The testcase poc is from this web page.</preline>
</pre>
<pre>
<preline> ==17411==ERROR: AddressSanitizer: heap-buffer-overflow on address</preline>
<preline> 0xf3808904 at pc 0x80a6f76 bp 0xffb95e78 sp 0xffb95a5c</preline>
<preline> READ of size 4 at 0xf3808904 thread T0</preline>
<preline> ==17411==WARNING: Trying to symbolize code, but external symbolizer is</preline>
<preline> not initialized!</preline>
<preline> #0 0x80a6f75 in __interceptor_memcpy ??:?</preline>
<preline> #1 0x8426c3b in _dwarf_read_loc_section</preline>
<preline> /home/starlab/fuzzing/dwarf-20160613/libdwarf/./dwarf_loc.c:919</preline>
<preline> #2 0x84250e2 in _dwarf_get_loclist_count</preline>
<preline> /home/starlab/fuzzing/dwarf-20160613/libdwarf/./dwarf_loc.c:970</preline>
<preline> #3 0x8438826 in dwarf_get_loclist_c</preline>
<preline> /home/starlab/fuzzing/dwarf-20160613/libdwarf/./dwarf_loc2.c:551</preline>
<preline> #4 0x81a1be8 in get_location_list</preline>
<preline> /home/starlab/fuzzing/dwarf-20160613/dwarfdump/print_die.c:3523</preline>
<preline> #5 0x816e1a2 in print_attribute</preline>
</pre>
_dwarf_get_loclist_header_start() is not cautious about values
in the header being absurdly large.
Unclear as yet if this is the problem
but it is a potential problem (fixed for next release).
<pre>
<preline> Address Sanitizer in gcc reproduces the report.</preline>
<preline> In _dwarf_read_loc_section() the simple calculation of</preline>
<preline> loc_section_end was wrong, so end-of section was</preline>
<preline> incorrect for the local reads.</preline>
<preline> With that fixed we get DW_DLE_READ_LITTLEENDIAN_ERROR when</preline>
<preline> libdwarf attempts to read off end of section.</preline>
</pre>
</description>
<datefixed>2016-09-23</datefixed>
<references> regressiontests/DW201609-003/poc
</references>
<gitfixid>3767305debcba8bd7e1c483ae48c509d25399252</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201609-002</dwid>
<cve>CVE-2016-7511</cve>
<fuzzer></fuzzer>
<datereported>2016-09-18</datereported>
<reportedby>Shi Ji (@Puzzor)</reportedby>
<product>libdwarf</product>
<vulnerability> libdwarf 20160613 Integer Overflow
</vulnerability>
<description> In dwarf_get_size_of_val() with
fuzzed DWARF data we get a SEGV.
<pre>
<preline> See</preline>
<preline> https://sourceforge.net/p/libdwarf/bugs/3/</preline>
</pre>
<pre>
<preline> ==6825== ERROR: AddressSanitizer: SEGV on unknown address 0x0583903c (pc 0xb61f1a98 sp 0xbfa388b4 bp 0xbfa38d08 T0)</preline>
<preline> AddressSanitizer can not provide additional info.</preline>
<preline> #1 0xb61e3c0b (/usr/lib/i386-linux-gnu/libasan.so.0+0xdc0b)</preline>
<preline> #2 0x80a21b1 in _dwarf_get_size_of_val /home/fuzzing/fuzzing/dwarf-20160613/libdwarf/dwarf_util.c:210</preline>
<preline> #3 0x8054214 in _dwarf_next_die_info_ptr /home/fuzzing/fuzzing/dwarf-20160613/libdwarf/dwarf_die_deliv.c:1340</preline>
<preline> #4 0x80557a5 in dwarf_child /home/fuzzing/fuzzing/dwarf-20160613/libdwarf/dwarf_die_deliv.c:1640</preline>
<preline> #5 0x804b23f in get_die_and_siblings /home/fuzzing/fuzzing/dwarf-20160613/dwarfexample/./simplereader.c:573</preline>
</pre>
_dwarf_make_CU_Context() is insufficiently cautious about
the length of a CU being absurd.
Unclear as yet if this is the problem
but it is a problem and is fixed for next release.
</description>
<datefixed>2016-09-23</datefixed>
<references> regressiontests/DW201609-002/DW201609-002-poc
</references>
<gitfixid>3767305debcba8bd7e1c483ae48c509d25399252</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201609-001</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2016-09-16</datereported>
<reportedby>STARLAB</reportedby>
<product>libdwarf</product>
<vulnerability> libdwarf 20160613 die_info_ptr in dwarf_die_deliv.c: 1533 Out-Of_bounds
</vulnerability>
<description> At line 1533 of dwarf_die_deliv.c a
pointer dereference is done with a pointer pointing
past the end of the CU data.
<pre>
<preline> see</preline>
<preline> https://sourceforge.net/p/libdwarf/bugs/2/</preline>
</pre>
<pre>
<preline> ==8054==ERROR: AddressSanitizer: heap-buffer-overflow on</preline>
<preline> address 0xf4c027ab at pc 0x819e4a4 bp 0xff88eb38 sp 0xff88eb30</preline>
<preline> READ of size 1 at 0xf4c027ab thread T0</preline>
<preline> #0 0x819e4a3 in dwarf_siblingof_b /home/starlab/fuzzing/dwarf-20160613/libdwarf/dwarf_die_deliv.c:1533</preline>
<preline> #1 0x8116201 in print_die_and_children_internal /home/starlab/fuzzing/dwarf-20160613/dwarfdump/print_die.c:1157</preline>
<preline> Bug report on sourceforge.net bug list for libdwarf.</preline>
<preline> The bad pointer dereference is due to libdwarf</preline>
<preline> not noticing that the DWARF in that file is corrupt.</preline>
<preline> In addition</preline>
<preline> The code was not noticing that it could dereference</preline>
<preline> a pointer that pointed out of bounds in the end-sibling-list</preline>
<preline> loop.</preline>
</pre>
<pre>
<preline> The example from the bug report (DW201609-001-poc) has</preline>
<preline> the same problem.</preline>
<preline> dwarfdump now reports DW_DLE_SIBLING_LIST_IMPROPER</preline>
<preline> on both test2.o and DW201609-001-poc.</preline>
</pre>
</description>
<datefixed>2016-09-17</datefixed>
<references> regressiontests/DW201609-001/test2.o
regressiontests/DW201609-001/DW201609-001-poc
</references>
<gitfixid>3767305debcba8bd7e1c483ae48c509d25399252</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-020</dwid>
<cve>CVE-2016-5027</cve>
<fuzzer></fuzzer>
<datereported>2016-04-25</datereported>
<reportedby>Yue Liu,lieanu</reportedby>
<product>libdwarf</product>
<vulnerability> NULL dereference in _dwarf_decode_s_leb128
</vulnerability>
<description> dwarf_form.c in libdwarf 20160115 allows
remote attackers to cause a denial of service (crash)
via a crafted elf file
Apparently no crafted object file presented.
However the code fix is presented in the report
at openwall.com.
Discovered the CVE November 2021
To attack the code just pass the argument
Dwarf_Word * leb128_length as a NULL pointer (that is allowed).
The code was fixed in dwarf_leb.c on 2016-04-27 20:00:06.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1330237</preline>
<preline> www.openwall.com/lists/oss-security/2016/05/24/1</preline>
<preline> www.openwall.com/lists/oss-security/2016/05/25/1</preline>
</pre>
</description>
<datefixed>2016-05-27</datefixed>
<references></references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-019</dwid>
<cve>CVE-2016-5028</cve>
<fuzzer></fuzzer>
<datereported>2016-05-23</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference in print_frame_inst_bytes (dwarfdump)
</vulnerability>
<description> The null dereference is due to a corrupted
object file. Libdwarf was not dealing with empty (bss-like)
sections since it really did not expect to see such in
sections it reads! Now libdwarf catches the object error
so dwarfdump sees the section as empty (as indeed it is!).
</description>
<datefixed>2016-05-23</datefixed>
<references> regressiontests/liu/NULLdeference0522c.elf
</references>
<gitfixid>a55b958926cc67f89a512ed30bb5a22b0adb10f4</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-018</dwid>
<cve>CVE-2016-5029</cve>
<fuzzer></fuzzer>
<datereported>2016-05-22</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference in create_fullest_file_path().
</vulnerability>
<description> The null dereference in create_fullest_file_path()
causes a crash. This is due to corrupted dwarf and the fix
detects this corruption and if that null string pointer
happens undetected a static string is substituted so
readers can notice the situation.
<pre>
<preline> 202 }</preline>
<preline> 203 if (dirno > 0 && fe->fi_dir_index > 0) {</preline>
<preline> 204 inc_dir_name = (char *)</preline>
<preline> line_context->lc_include_directories[</preline>
<preline> 205 fe->fi_dir_index - 1];</preline>
<preline> 206 incdirnamelen = strlen(inc_dir_name); <- $pc</preline>
<preline> 207 }</preline>
<preline> 208 full_name = (char *) _dwarf_get_alloc(dbg,</preline>
<preline> #0 create_fullest_file_path (dbg=<optimized out>,</preline>
<preline> fe=0x68d510, line_context=0x68c4f0, name_ptr_out=<optimized</preline>
<preline> out>, error=0x7fffffffe2b8) at ./dwarf_line.c:206</preline>
<preline> #1 0x00007ffff7b6d3f9 in dwarf_filename (context=<optimized</preline>
<preline> out>, fileno_in=<optimized out>, ret_filename=0x7fffffffe280,</preline>
<preline> error=0x7fffffffe2b8) at ./dwarf_line.c:1418</preline>
<preline> #2 dwarf_linesrc (line=<optimized out>,</preline>
<preline> ret_linesrc=<optimized out>, error=<optimized out>) at</preline>
<preline> ./dwarf_line.c:1436</preline>
</pre>
</description>
<datefixed>2016-05-22</datefixed>
<references> regressiontests/liu/NULLdereference0522.elf
</references>
<gitfixid>acae971371daa23a19358bc62204007d258fbc5e</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-017</dwid>
<cve>CVE-2016-5030</cve>
<fuzzer></fuzzer>
<datereported>2016-05-19</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> Null dereference bug in _dwarf_calculate_info_section_end_ptr().
</vulnerability>
<description> NULL dereference bug in _dwarf_calculate_info_section_end_ptr().
<pre>
<preline> 1742 Dwarf_Off off2 = 0;</preline>
<preline> 1743 Dwarf_Small *dataptr = 0;</preline>
<preline> 1744</preline>
<preline> 1745 dbg = context->cc_dbg;</preline>
<preline> 1746 dataptr = context->cc_is_info? dbg->de_debug_info.dss_data: <- $pc</preline>
<preline> 1747 dbg->de_debug_types.dss_data;</preline>
<preline> 1748 off2 = context->cc_debug_offset;</preline>
<preline> 1749 info_start = dataptr + off2;</preline>
<preline> 1750 info_end = info_start + context->cc_length +</preline>
<preline> #0 _dwarf_calculate_info_section_end_ptr</preline>
<preline> (context=context@entry=0x0) at dwarf_query.c:1746</preline>
<preline> #1 0x00002aaaaace307d in</preline>
<preline> _dwarf_extract_string_offset_via_str_offsets</preline>
<preline> (dbg=dbg@entry=0x655a70, info_data_ptr=0x6629f0</preline>
<preline> "", attrnum=attrnum@entry=121,</preline>
<preline> attrform=attrform@entry=26, cu_context=0x0,</preline>
<preline> str_sect_offset_out=str_sect_offset_out@entry=0x7fffffffd718,</preline>
<preline> error=error@entry=0x7fffffffd878) at dwarf_form.c:1099</preline>
<preline> #2 0x00002aaaaacf4ed7 in dwarf_get_macro_defundef</preline>
<preline> (macro_context=macro_context@entry=0x65b790,</preline>
<preline> op_number=op_number@entry=1,</preline>
<preline> line_number=line_number@entry=0x7fffffffd858,</preline>
<preline> index=index@entry=0x7fffffffd860,</preline>
<preline> offset=offset@entry=0x7fffffffd868,</preline>
<preline> forms_count=forms_count@entry=0x7fffffffd7ce,</preline>
<preline> macro_string=macro_string@entry=0x7fffffffd870,</preline>
<preline> error=error@entry=0x7fffffffd878) at dwarf_macro5.c:557</preline>
<preline> ------</preline>
<preline> _dwarf_calculate_info_section_end_ptr (context=context@entry=0x0) at</preline>
<preline> dwarf_query.c:1746</preline>
<preline> 1746 dataptr = context->cc_is_info? dbg->de_debug_info.dss_data:</preline>
<preline> gef> p/x $rdi</preline>
<preline> $4 = 0x0</preline>
</pre>
</description>
<datefixed>2016-05-22</datefixed>
<references> regressiontests/liu/NULLdereference0519.elf
</references>
<gitfixid>6fa3f710ee6f21bba7966b963033a91d77c952bd</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-016</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2016-05-19</datereported>
<reportedby>Yue Liu</reportedby>
<product>dwarfdump</product>
<vulnerability> Invalid dwarf leads to
dwarfdump crash in print_frame_inst_bytes.
</vulnerability>
<description> Corrupted dwarf crashes dwarfdump
<pre>
<preline> 1297 }</preline>
<preline> 1298 len = len_in;</preline>
<preline> 1299 endpoint = instp + len;</preline>
<preline> 1300 for (; len > 0;) {</preline>
<preline> 1301 unsigned char ibyte = *instp; <- $pc</preline>
<preline> 1302 int top = ibyte & 0xc0;</preline>
<preline> 1303 int bottom = ibyte & 0x3f;</preline>
<preline> 1304 int delta = 0;</preline>
<preline> 1305 int reg = 0;</preline>
<preline> #0 print_frame_inst_bytes (dbg=dbg@entry=0x655ca0,</preline>
<preline> cie_init_inst=<optimized out>, len_in=<optimized out>,</preline>
<preline> data_alignment_factor=-4, code_alignment_factor=4,</preline>
<preline> addr_size=addr_size@entry=4, offset_size=4, version=3,</preline>
<preline> config_data=config_data@entry=0x63cda0 <g_config_file_data>)</preline>
<preline> at print_frames.c:1301</preline>
<preline> #1 0x000000000041b70c in print_one_cie</preline>
<preline> (dbg=dbg@entry=0x655ca0, cie=<optimized out>,</preline>
<preline> cie_index=cie_index@entry=2, address_size=<optimized out>,</preline>
<preline> config_data=config_data@entry=0x63cda0 <g_config_file_data>)</preline>
<preline> at print_frames.c:1161</preline>
<preline> #2 0x000000000041cf52 in print_frames (dbg=0x655ca0,</preline>
<preline> print_debug_frame=print_debug_frame@entry=1, print_eh_frame=0,</preline>
<preline> config_data=config_data@entry=0x63cda0 <g_config_file_data>)</preline>
<preline> at print_frames.c:2229</preline>
<preline> gef> p/x $r13</preline>
<preline> $1 = 0x4bcad8</preline>
<preline> gef> p/x *$r13</preline>
<preline> Cannot access memory at address 0x4bcad8</preline>
</pre>
</description>
<datefixed>2016-05-22</datefixed>
<references> regressiontests/liu/OOB_READ0519.elf
</references>
<gitfixid>6fa3f710ee6f21bba7966b963033a91d77c952bd</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-015</dwid>
<cve>CVE-2016-5031</cve>
<fuzzer></fuzzer>
<datereported>2016-05-17</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in print_frame_inst_bytes()
</vulnerability>
<description> Test object shows
an invalid read in print_frame_inst_bytes().
<pre>
<preline> 1294 for (; len > 0;) {</preline>
<preline> 1295 unsigned char ibyte = *instp; <- $pc</preline>
<preline> 1296 int top = ibyte & 0xc0;</preline>
<preline> #0 print_frame_inst_bytes (dbg=dbg@entry=0x654c80,</preline>
<preline> cie_init_inst=<optimized out>, len=503715, data_alignment_factor=-4,</preline>
<preline> code_alignment_factor=1, addr_size=addr_size@entry=4, offset_size=4,</preline>
<preline> version=3, config_data=config_data@entry=0x63bda0</preline>
<preline> <g_config_file_data>) at print_frames.c:1295</preline>
<preline> #1 0x000000000041b64c in print_one_cie (dbg=dbg@entry=0x654c80,</preline>
<preline> cie=<optimized out>, cie_index=cie_index@entry=1,</preline>
<preline> address_size=<optimized out>, config_data=</preline>
<preline> config_data@entry=0x63bda0 <g_config_file_data>) at print_frames.c:1161</preline>
<preline> #2 0x000000000041ce92 in print_frames (dbg=0x654c80,</preline>
<preline> print_debug_frame=print_debug_frame@entry=1, print_eh_frame=0,</preline>
<preline> config_data=config_data@entry=0x63bda0 <g_config_file_data>)</preline>
<preline> at print_frames.c:2209</preline>
<preline> gef> x/10x $r13</preline>
<preline> 0x5e7981: Cannot access memory at address 0x5e7981</preline>
<preline> gef> p/x $r13</preline>
<preline> $14 = 0x5e7981</preline>
</pre>
</description>
<datefixed>2015-05-18</datefixed>
<references> regressiontests/liu/OOB0517_03.elf
</references>
<gitfixid>ac6673e32f3443a5d36c2217cb814000930b2c54</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-014</dwid>
<cve>CVE-2016-5032</cve>
<fuzzer></fuzzer>
<datereported>2016-05-17</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in dwarf_get_xu_hash_entry()
</vulnerability>
<description> Test object shows
an invalid read in dwarf_get _xu_hash_entry, lin 211.
<pre>
<preline> #0 dwarf_get_xu_hash_entry (xuhdr=xuhdr@entry=0x657360,</preline>
<preline> index=index@entry=2897626028, hash_value=</preline>
<preline> hash_value@entry=0x7fffffffd5b0,</preline>
<preline> index_to_sections=index_to_sections@entry=0x7fffffffd5a8,</preline>
<preline> err=err@entry=0x7fffffffdb08) at dwarf_xu_index.c:211</preline>
<preline> #1 0x00002aaaaacfd05e in _dwarf_search_fission_for_key (</preline>
<preline> dbg=0x654a50, error=0x7fffffffdb08, percu_index_out=<synthetic pointer>,</preline>
<preline> key_in=0x7fffffffd670, xuhdr=0x657360) at dwarf_xu_index.c:363</preline>
<preline> #2 dwarf_get_debugfission_for_key (dbg=dbg@entry=0x654a50,</preline>
<preline> key=key@entry=0x7fffffffd670, key_type=key_type@entry=0x2aaaaad15e2a</preline>
<preline> "tu", percu_out=percu_out@entry=0x65a830,</preline>
<preline> error=error@entry=0x7fffffffdb08) at dwarf_xu_index.c:577</preline>
</pre>
</description>
<datefixed>2015-05-18</datefixed>
<references> regressiontests/liu/OOB0517_02.elf
</references>
<gitfixid>ac6673e32f3443a5d36c2217cb814000930b2c54</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-013</dwid>
<cve>CVE-2016-5033</cve>
<fuzzer></fuzzer>
<datereported>2016-05-17</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in print_exprloc_content
</vulnerability>
<description> Test object shows
an invalid write in print_exprloc_content.
<pre>
<preline> #0 print_exprloc_content (dbg=dbg@entry=0x654ea0,</preline>
<preline> die=die@entry=0x65b110, attrib=attrib@entry=0x65b590,</preline>
<preline> esbp=esbp@entry=0x7fffffffcef0, showhextoo=1) at print_die.c:4182</preline>
<preline> #1 0x0000000000412fb1 in get_attr_value (dbg=dbg@entry=0x654ea0,</preline>
<preline> tag=<optimized out>, die=die@entry=0x65b110,</preline>
<preline> dieprint_cu_goffset=dieprint_cu_goffset@entry=11,</preline>
<preline> attrib=attrib@entry=0x65b590, srcfiles=srcfiles@entry=0x0,</preline>
<preline> cnt=cnt@entry=0, esbp=esbp@entry=0x7fffffffcef0, show_form=0,</preline>
<preline> local_verbose=0) at print_die.c:4972</preline>
</pre>
</description>
<datefixed>2015-05-18</datefixed>
<references> regressiontests/liu/OOB0517_01.elf
</references>
<gitfixid>ac6673e32f3443a5d36c2217cb814000930b2c54</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-012</dwid>
<cve>CVE-2016-5034</cve>
<fuzzer></fuzzer>
<datereported>2016-05-13</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB write. From relocation records
</vulnerability>
<description> Test object shows
an invalid write in dwarf_elf_access.c
(when doing the relocations).
Adding the relocation value to anything overflowed
and disguised the bad relocation record.
With a 32bit kernel build the test could show
a double-free and coredump due to the unchecked invalid
writes from relocations.
</description>
<datefixed>2016-05-17</datefixed>
<references> regressiontests/liu/HeapOverflow0513.elf
</references>
<gitfixid>10ca310f64368dc083efacac87732c02ef560a92</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-011</dwid>
<cve>CVE-2016-5035</cve>
<fuzzer></fuzzer>
<datereported>2016-05-06</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in _dwarf_read_line_table_header
</vulnerability>
<description> Test object shows
null dereference at line 62
of dwarf_line_table_reader.c.
Frame code and linetable code was not noticing data corruption.
</description>
<datefixed>2016-05-12</datefixed>
<references> regressiontests/liu/OOB_read4.elf
</references>
<gitfixid>82d8e007851805af0dcaaff41f49a2d48473334b</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-010</dwid>
<cve>CVE-2016-5036</cve>
<fuzzer></fuzzer>
<datereported>2016-05-06</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in dump_block
</vulnerability>
<description> Test object shows
null dereverence at line 186
of dump_block() in print_sections.c
Frame code was not noticing frame data corruption.
</description>
<datefixed>2016-05-12</datefixed>
<references> regressiontests/liu/OOB_read3.elf
regressiontests/liu/OOB_read3_02.elf
</references>
<gitfixid>82d8e007851805af0dcaaff41f49a2d48473334b</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-009</dwid>
<cve>CVE-2016-5037</cve>
<fuzzer></fuzzer>
<datereported>2016-05-05</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> NULL dereference in _dwarf_load_section
</vulnerability>
<description> Test object shows
null dereverence at line 1010
if(!strncmp("ZLIB",(const char *)src,4)) {
in dwarf_init_finish.c
The zlib code was not checking for
a corrupted length-value.
</description>
<datefixed>2016-05-06</datefixed>
<references> regressiontests/liu/NULLderefer0505_01.elf
</references>
<gitfixid>b6ec2dfd850929821626ea63fb0a752076a3c08a</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-008</dwid>
<cve>CVE-2016-5038</cve>
<fuzzer></fuzzer>
<datereported>2016-05-05</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read in dwarf_get_macro_startend_file()
</vulnerability>
<description> Test object shows
out of bound read.
OOB at:
line 772 *src_file_name = macro_context->mc_srcfiles[trueindex];
in dwarf_macro5.c
A string offset into .debug_str is outside the bounds
of the .debug_str section.
</description>
<datefixed>2016-05-12</datefixed>
<references> regressiontests/liu/OOB0505_02.elf
regressiontests/liu/OOB0505_02_02.elf
</references>
<gitfixid>82d8e007851805af0dcaaff41f49a2d48473334b</gitfixid>
<tarrelease>libdwarf-20160923.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-007</dwid>
<cve>CVE-2016-5039</cve>
<fuzzer></fuzzer>
<datereported>2016-05-05</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> OOB read bug in get_attr_value()
</vulnerability>
<description> Test object shows
out of bound read.
Object had data all-bits-on so
the existing length check did not work
due to wraparound. Added a check
not susceptible to that error (DW_DLE_FORM_BLOCK_LENGTH_ERROR).
</description>
<datefixed>2016-05-06</datefixed>
<references> regressiontests/liu/OOB0505_01.elf
</references>
<gitfixid>eb1472afac95031d0c9dd8c11d527b865fe7deb8</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-006</dwid>
<cve></cve>
<fuzzer></fuzzer>
<datereported>2016-05-05</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> Two Heap-Overflow bug
</vulnerability>
<description> Two test objects showing
a heap overflow in libdwarf when
using dwarfdump.
It seems that these were fixed
by the previous git update.
Neither gdb nor valgrind find any errors
when building with yesterday's commit.
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/free_invalid_address.elf
regressiontests/liu/heapoverflow01b.elf
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-005</dwid>
<cve>CVE-2016-5040</cve>
<fuzzer></fuzzer>
<datereported>2016-05-02</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> A specially crafted DWARF section
results in reading a compilation unit header
that crashes the application.
</vulnerability>
<description> If the data read for a compilation unit header
contains a too large length value the library
will read outside of its bounds and crash the application.
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/null02.elf
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1332149</preline>
</pre>
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-004</dwid>
<cve>CVE-2016-5041</cve>
<fuzzer></fuzzer>
<datereported>2016-05-02</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> A specially crafted DWARF section
results in a null dereference reading debugging
information entries which
crashes the application.
</vulnerability>
<description> If no DW_AT_name is present in a debugging
information entry using DWARF5 macros
a null dereference in dwarf_macro5.c will
crash the application.
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/null01.elf
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1332148</preline>
</pre>
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-003</dwid>
<cve>CVE-2016-5042</cve>
<fuzzer></fuzzer>
<datereported>2016-05-02</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> A specially crafted DWARF section
results in an infinite loop that eventually
crashes the application.
</vulnerability>
<description> In dwarf_get_aranges_list()
an invalid count will iterate, reading from memory
addresses that increase till it all fails.
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/infiniteloop.elf
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1332145</preline>
</pre>
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-002</dwid>
<cve>CVE-2016-5043</cve>
<fuzzer></fuzzer>
<datereported>2016-05-02</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> A specially crafted DWARF section
results in a read outside the bounds of in memory
data so the calling application can crash.
</vulnerability>
<description> Out of bound read bug in libdwarf git code.
dwarf_dealloc() did not check the Dwarf_Ptr space argument
before using it. This will lead to a out-of-bound read bug.
<pre>
<preline> backtrace:</preline>
<preline> #0 dwarf_dealloc (dbg=dbg@entry=0x655f30, space=0xa0,</preline>
<preline> alloc_type=alloc_type@entry=1) at dwarf_alloc.c:477</preline>
<preline> #1 0x00002aaaaacf3296 in dealloc_srcfiles</preline>
<preline> (dbg=0x655f30, srcfiles=0x66b8f0, srcfiles_count=17) at</preline>
<preline> dwarf_macro5.c:1025 #2 0x00002aaaaacf50e6 in dealloc_srcfiles</preline>
<preline> (srcfiles_count=<optimized out>, srcfiles=<optimized out>,</preline>
<preline> dbg=<optimized out>) at dwarf_macro5.c:1021 -----</preline>
<preline> gef> p &r->rd_dbg</preline>
<preline> $14 = (void **) 0x90</preline>
</pre>
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/outofbound01.elf
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1332144</preline>
</pre>
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201605-001</dwid>
<cve>CVE-2016-5044</cve>
<fuzzer></fuzzer>
<datereported>2016-05-02</datereported>
<reportedby>Yue Liu</reportedby>
<product>libdwarf</product>
<vulnerability> A specially crafted DWARF section
results in a duplicate free() in libdwarf and
the calling application will crash.
</vulnerability>
<description> In file dwarf_elf_access.c:1071
<pre>
<preline> WRITE_UNALIGNED(dbg,target_section + offset,</preline>
<preline> &outval,sizeof(outval),reloc_size);</preline>
</pre>
A crafted ELF file may lead to a large offset value, which
bigger than the size of target_section heap chunk, then this
WRITE_UNALIGNED() function will write the value of &outval
out of the heap chunk.
offset is a 64bit unsigned int value, so this is more than
a heap overflow bug, but also a Out-of-Bound write bug.
So WRITE_UNALIGNED() need more strictly checking to prevent
this.
</description>
<datefixed>2016-05-04</datefixed>
<references> regressiontests/liu/heapoverflow01.elf
<pre>
<preline> https://bugzilla.redhat.com/show_bug.cgi?id=1332141</preline>
</pre>
</references>
<gitfixid>98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201601-002</dwid>
<cve>CVE-2016-2050</cve>
<fuzzer></fuzzer>
<datereported>2016-01-19</datereported>
<reportedby>Qixue Xiao</reportedby>
<product>libdwarf</product>
<vulnerability> Out of bound write in get_abbrev_array_info
</vulnerability>
<description> Crashes the calling program. Requires
a crafted object file.
<pre>
<preline> valgrind ./dwarfdump -ka aw.elf</preline>
<preline> ==5358== Memcheck, a memory error detector</preline>
<preline> ==5358== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.</preline>
<preline> ==5358== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info</preline>
<preline> ==5358== Command: ../../llvm-codes/dwarf-20151114/dwarfdump/dwarfdump -ka aw.elf</preline>
<preline> ==5358==</preline>
<preline> ==5358== Invalid write of size 8</preline>
<preline> ==5358== at 0x40DA25: get_abbrev_array_info (in</preline>
<preline> /home/xqx/test/libdwarf-test/llvm-codes/dwarf-20151114/dwarfdump/dwarfdump)</preline>
<preline> ==5358== by 0x40FD92: print_one_die_section (in</preline>
<preline> /home/xqx/test/libdwarf-test/llvm-codes/dwarf-20151114/dwarfdump/dwarfdump)</preline>
<preline> www.openwall.com/lists/oss-security/2016/01/19/9</preline>
<preline> www.openwall.com/lists/oss-security/2016/01/25/3</preline>
</pre>
</description>
<datefixed>2016-01-21</datefixed>
<references> regressiontests/xqx-b/aw.elf
</references>
<gitfixid>d9d40e4d802e626065ce37ff384dd69c43bc499</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201601-001</dwid>
<cve>CVE-2016-2091</cve>
<fuzzer></fuzzer>
<datereported>2016-01-12</datereported>
<reportedby>Qixue Xiao</reportedby>
<product>libdwarf</product>
<vulnerability> Out of bound read in dwarf_read_cie_fde_prefix()
</vulnerability>
<description> Crashes the calling program. Requires
a crafted object file.
<pre>
<preline> *** DWARF CHECK: DW_DLE_DEBUG_FRAME_LENGTH_NOT_MULTIPLE</preline>
<preline> len=0x00000010, len size=0x00000004, extn size=0x00000000, totl</preline>
<preline> length=0x00000014, addr size=0x00000008, mod=0x00000004 must be zero</preline>
<preline> in cie, offset 0x00000000. ***</preline>
<preline> 7 ==53495== Invalid read of size 2</preline>
<preline> 1 ==53495== at 0x4C2F7E0: memcpy@@GLIBC_2.14 (in</preline>
<preline> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)</preline>
<preline> 2 ==53495== by 0x43287F: dwarf_read_cie_fde_prefix (dwarf_frame2.c:934)</preline>
<preline> 3 ==53495== by 0x431305: _dwarf_get_fde_list_internal (dwarf_frame2.c:268)</preline>
<preline> 4 ==53495== by 0x42EB5F: dwarf_get_fde_list_eh (dwarf_frame.c:1101)</preline>
<preline> 5 ==53495== by 0x41BABE: print_frames (print_frames.c:1835)</preline>
<preline> 6 ==53495== by 0x40485B: process_one_file (dwarfdump.c:1323)</preline>
<preline> 7 ==53495== by 0x403529: main (dwarfdump.c:630)</preline>
<preline> www.openwall.com/lists/oss-security/2016/01/19/3</preline>
<preline> www.openwall.com/lists/oss-security/2016/05/28/8</preline>
</pre>
</description>
<datefixed>2016-01-21</datefixed>
<references> regressiontests/xqx-b/awbug5.elf
</references>
<gitfixid>d9d40e4d802e626065ce37ff384dd69c43bc499</gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201512-002</dwid>
<cve>CVE-2015-8538</cve>
<fuzzer></fuzzer>
<datereported>2015-12-14</datereported>
<reportedby>Adam Maris</reportedby>
<product>libdwarf</product>
<vulnerability> Out-of-bounds read in dwarf_leb.c
</vulnerability>
<description> libdwarf 20151114 and earlier allows remote
attackers to cause a denial of service (NULL pointer
dereference and crash) via a debug_abbrev
section marked NOBITS in an ELF file.
The CVE report mentions a reproducer object file
but such is not present.
Due to recent tool advances (like
coverity scan) we are confident this was fixed long ago.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1291299</preline>
<preline> www.openwall.com/lists/oss-security/2015/12/10/3</preline>
</pre>
</description>
<datefixed>2018-01-01</datefixed>
<references></references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201512-001</dwid>
<cve>CVE-2015-8750</cve>
<fuzzer></fuzzer>
<datereported>2015-12-26</datereported>
<reportedby>Qixue Xiao (xqx)</reportedby>
<product>libdwarf</product>
<vulnerability> Null pointer dereference in libdwarf
</vulnerability>
<description> libdwarf 20151114 and earlier allows remote
attackers to cause a denial of service (NULL pointer
dereference and crash) via a debug_abbrev
section marked NOBITS in an ELF file.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1294264</preline>
<preline> www.openwall.com/lists/oss-security/2016/01/07/11</preline>
</pre>
</description>
<datefixed>2015-12-31</datefixed>
<references> regressiontests/xqx-c/awbug6.elf
</references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
<dwbug>
<dwid>DW201412-001</dwid>
<cve>CVE-2014-9482</cve>
<fuzzer></fuzzer>
<datereported>2014-12-31</datereported>
<reportedby>Adam Maris</reportedby>
<product>dwarfdump</product>
<vulnerability> Use after free vulnerability in Dwarfdump
</vulnerability>
<description> The use-after-free has no attached testcase
anywhere. Due to recent tool advances (like
coverity scan) we are confident this was fixed long ago.
<pre>
<preline> bugzilla.redhat.com/show_bug.cgi?id=1177758</preline>
<preline> www.openwall.com/lists/oss-security/2014/12/31/3</preline>
<preline> www.openwall.com/lists/oss-security/2015/01/03/14</preline>
</pre>
</description>
<datefixed>2018-01-01</datefixed>
<references></references>
<gitfixid></gitfixid>
<tarrelease>libdwarf-20160507.tar.gz</tarrelease>
</dwbug>
</dwarfbug>