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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
