A stack-overflow in tinycc-f150f93/tccpp.c

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

A stack-overflow in tinycc-f150f93/tccpp.c

magic googlo
commit:f150f93854a10f1e02d701c73126035a069d3e54
vuln:stack-overflow
Credits:Taolaw
To reproduce, compile the attached input file with tcc

    tcc stack-overflow.c
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-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

stack-overflow.c (160K) Download Attachment
crash.log (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A stack-overflow in tinycc-f150f93/tccpp.c

Daniel Glöckner-2
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

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

tcc-cycles.dot (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A stack-overflow in tinycc-f150f93/tccpp.c

Pascal Cuoq
Hello,

> On 29 Dec 2019, at 23:31, Daniel Glöckner <[hidden email]> wrote:
>
> Adding recursion depth limitation into all cycles of this graph is a
> lot of work.

It would also be counter-productive. Currently it takes a single ulimit command to compile a larger-than-usual program, but if tcc enforced its own limits there would be several settings to tweak.

I don't know any compiler that does not stack overflow on sufficiently large inputs. Tcc is only structured in a way that a dumb fuzzer can find an input that produces this behavior by just repeating the character *. This does not sound like a security issue, or even an issue.

Pascal
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: A stack-overflow in tinycc-f150f93/tccpp.c

Christian Jullien-3
I once wrote a C++ program using a huge constexpr std::array having a lot a ctor (also constexpr). Gcc miserably failed with a core dump after more than 1mn of compilation.
In a sense, tcc is gcc compatible :o)

C.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Pascal Cuoq
Sent: Monday, December 30, 2019 05:51
To: [hidden email]
Subject: Re: [Tinycc-devel] A stack-overflow in tinycc-f150f93/tccpp.c

Hello,

> On 29 Dec 2019, at 23:31, Daniel Glöckner <[hidden email]> wrote:
>
> Adding recursion depth limitation into all cycles of this graph is a
> lot of work.

It would also be counter-productive. Currently it takes a single ulimit command to compile a larger-than-usual program, but if tcc enforced its own limits there would be several settings to tweak.

I don't know any compiler that does not stack overflow on sufficiently large inputs. Tcc is only structured in a way that a dumb fuzzer can find an input that produces this behavior by just repeating the character *. This does not sound like a security issue, or even an issue.

Pascal
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel