[llvm-bugs] [Bug 40861] New: llvm-readobj reads past end of dynamic segment if it does not end in DT_NULL

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40861

            Bug ID: 40861
           Summary: llvm-readobj reads past end of dynamic segment if it
                    does not end in DT_NULL
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-readobj
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: jh7370.2008 at my.bristol.ac.uk, llvm-bugs at lists.llvm.org

Generating a dynamic segment with the following yaml results in there being no
DT_NULL entry at the end of the segment:
--- !ELF
FileHeader:
  Class:   ELFCLASS64
  Data:    ELFDATA2LSB
  Type:    ET_EXEC
  Machine: EM_X86_64
Sections:
  - Name:         .dynamic
    Type:         SHT_DYNAMIC
    AddressAlign: 0x10
    Address:      0x1010
    # DT_DEBUG tag only, no DT_NULL tag.
    Content: "15000000000000000000000000000000"
ProgramHeaders:
  - Type: PT_LOAD
    VAddr: 0x1000
    Sections:
      - Section: .dynstr
      - Section: .dynamic
  - Type: PT_DYNAMIC
    VAddr: 0x1010
    Sections:
      - Section: .dynamic

Although strictly speaking this is illegal, GNU readelf handles it sensibly,
because the size is listed in the program header:
C:\Work> readelf --dynamic test.tmp.no-null

Dynamic section at offset 0x1f0 contains 1 entries:
  Tag        Type                         Name/Value
 0x0000000000000015 (DEBUG)              0x0

However, llvm-readobj does not. It assumes that there is always a trailing
DT_NULL entry, and reads past the end of the segment if there is none to find
it:
C:\Work> llvm-readobj.exe --dynamic-table test.tmp.no-null
<snip>
DynamicSection [ (2 entries)
  Tag                Type                 Name/Value
  0x0000000000000015 DEBUG                0x0
  0x0000000000000000 NULL                 0x0
]

I'm guessing, but don't know for sure, that the non-existent NULL entry is
printed as such because the next 16 bytes happen to be all 0 in the file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190226/43e70ec8/attachment.html>