[lld] r256309 - Fix two asan found bugs:

[Rui Ueyama via llvm-commits]

I'm pretty sure that you can crash lld by giving corrupted object files if
you know how to do that because there are some corner cases that we do not
check all inputs vigorously. For example, I believe the file size in the
header is not checked if it's equal or smaller than the actual file size,
so it could overrun. Or, if a relocation has a way large offset, it could
overrun the current output buffer, etc, etc.

That's not an issue at least for now because lld just crashes for broken
object files and nothing worse than that would happen. It would bring us
back to the process/library argument, but as I said that's not a focus now.
Anyway, object files are created by compilers and unless it is buggy we do
not generally see any broken object files, so in reality it's not going to
be an issue.

On Wed, Jan 13, 2016 at 1:35 PM, Rafael Espíndola <
llvm-commits at lists.llvm.org> wrote:

> On 4 January 2016 at 13:33, Kostya Serebryany <kcc at google.com> wrote:
> > Cool!
> > I wonder if it makes sense to have a fuzzer for lld, similar to what we
> have
> > for clang and clang-format?
>
> Maybe, it probably depends on what we are fuzzing for.
>
> Broken .o files are really uncommon, unless one is working on a
> producer (MC). For lld itself we have so far been using a "don't
> crash" policy, but not much more. For example, we will produce garbage
> if given ABI invalid TLS relocations.
>
> Cheers,
> Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160113/bf4845b3/attachment-0001.html>