tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] A stack-overflow in tinycc-f150f93/tccpp.c


From: Daniel Glöckner
Subject: Re: [Tinycc-devel] A stack-overflow in tinycc-f150f93/tccpp.c
Date: Sun, 29 Dec 2019 23:29:59 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

On Tue, Dec 24, 2019 at 01:12:55PM +0800, magic googlo wrote:
> The attachment includes the error message of stack-overflow.c and asan that
> triggered the crash. Hope to help you fix this bug as soon as possible

tinycc relies heavily on recursion and AFAIK it nowhere limits the
recursion depth. Attached you can find a graph that contains only the
cycles from tinycc's call graph (when compiled for x86-64 Linux).
The call graph was generated by adding a printf to gcall_or_jmp. The few
indirect calls have been resolved manually. Afterwards I have filtered
the graph iteratively with shell commands and converted it to a dot
file.

Adding recursion depth limitation into all cycles of this graph is a
lot of work. And if we add limitations, the question is how many
recursions we allow. In your example the stack overflow was caused by
lots of pointer dereferences. It is possible to write a valid C program
that contains more pointer dereferences in a row than your example.
Why should tinycc reject it?

As far as I can see the worst that can happen is that your system runs
out of memory. Or are there systems where the stack might be extended
until it connects to other allocated memory areas? I suggest that you
limit the size of the stack with ulimit -s or compile tcc with a
compiler that can instrument the code to prevent stack overflows if you
have to compile untrusted source code.

Best regards,

  Daniel

Attachment: tcc-cycles.dot
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]