[Bug binutils/20499] gprof: segmentation fault on invalid symbol file

[tobias at stoeckmann dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20499

--- Comment #10 from Tobias Stoeckmann <tobias at stoeckmann dot org> ---
Challenge accepted. :D

So I investigated this. It is in fact possible to crash gprof with a "num"
overflow here. Let's consider the possible situations:

AMD64:

It is impossible to overflow a 64 bit size_t within sane boundaries. I might
stand corrected in 2030 or whatever, but by today, we don't have such large
files. Instead, we have to overflow "num" itself so it's back to zero. For
that, we need a file consisting of 2^32 lines. The shortest valid line is 7
bytes, which makes this file around 28 GB in size. Granted, I didn't test this
due to lack of patience. Let's instead go to...

I386:

Here, it is in fact possible to overflow a 32 bit size_t. We won't use a 28 GB
file here, because it could be that gprof is compiled without large file
support (in fact, my default binutils compilation supports large files). The
size of a Sym struct is 200 bytes, so let's do the math:

(SIZE_MAX+1) / sizeof(Sym) = 2^32 / 200 = 21474836.48

We want to overflow, so let's use 21474837 instead. As outlined before, the
shortest valid line is 7 bytes, so we end up with a 143 MB file. That's
manageable, even without large file support!

Proof of Concept:

$ for ((i = 0; i < 21474837; i++))
> do
>       echo "a t a"
> done > syms
$ gprof -S syms /bin/ls
Segmentation fault

Yes, the creation of syms can be sped up, but I don't want to cludder this
report with a more comprehensive script. And yes, the segmentation fault
resulted due to num-overflow, nothing else.

Hope this report was enjoyable to read, at least it was fun to figure out a
pathetic input like this again. :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.