[llvm-bugs] [Bug 48817] New: Don't read past end of relocation section in scanRelocs

[via llvm-bugs]

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

            Bug ID: 48817
           Summary: Don't read past end of relocation section in
                    scanRelocs
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: jh7370.2008 at my.bristol.ac.uk
                CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com

Given an input object that doesn't have the right relocations for a GD TLS
access, it's possible to read past the end of the relocation section, leading
to invalid reads/spurious error messages etc. This may not be the only case
either within the scanReloc code.

Example input:

.weak gd
leaq gd at tlsgd+64(%rip), %rdi

Output when linked:

ld.lld: error: unknown relocation (31) against symbol
ld.lld: error:
C:\llvm\build\tools\lld\test\ELF\Output\tls-weak-undef.s.tmpexec.o: invalid
symbol index

The problem is that a GD TLS access assumes there are two relocations. If the
second is missing, the linker doesn't notice this and the iteration termination
check doesn't fire, since it currently only terminates if the iterator equals
`end()`. In this case however, it is `end() + 1`, so the loop continues and
reads data outside the section.

The fix is to check there are actually two relocations remaining before
attempting to read or skip them.

-- 
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/20210120/be4ea1fa/attachment.html>