Bug 87636 - Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
Summary: Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-17 19:13 UTC by Cheng Wen
Modified: 2018-12-07 12:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
POC (142 bytes, text/plain)
2018-10-17 19:13 UTC, Cheng Wen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cheng Wen 2018-10-17 19:13:21 UTC
Created attachment 44850 [details]
POC

Dear all,

The following new binutils Stack-Overflow in libiberty was found by a modified version of the AFL fuzzer(MemFuzz). I have attached the crashing input and an ASAN report. I have confirmed them with address sanitizer too.

In this issue, Stack Exhaustion occurs in the C++ demangling functions provided by libiberty, and there are recursive stack frames in cp-demangle: cplus_demangle_type, d_bare_function_type, d_function_type. This can occur during the execution of "c++filt -t". I have also collected the different Stack Overflow problem recently appeared in c++filt, which I will list later. There may be some problems that need attention.

Please use the “./c++filt < $POC -t” to reproduce the bug. (Remember to add "-t" option and "<" Symbol)


Here is my compile Option. 

CC=clang LDFLAGS="-ldl" CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all -fsanitize=undefined,address -fno-omit-frame-pointer -g -O0 -Wno-error" ./configure --disable-shared --disable-gdb --disable-libdecnumber --disable-sim --prefix=$PWD/build/

> ASAN:DEADLYSIGNAL
> =================================================================
> ==28168==ERROR: AddressSanitizer: stack-overflow on address 0x7ffdfcdedf28 (pc 0x000002081a20 bp 0x7ffdfcdee0f0 sp 0x7ffdfcdedf28 T0)
>     #0 0x2081a1f in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2367
>     #1 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #2 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     #3 0x2086c1b in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2443:13
>     #4 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #5 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     #6 0x2086c1b in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2443:13
>     #7 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #8 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     #9 0x2086c1b in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2443:13
>     #10 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #11 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     #12 0x2086c1b in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2443:13
>     #13 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #14 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     #15 0x2086c1b in cplus_demangle_type binutils-gdb/libiberty/./cp-demangle.c:2443:13
>     #16 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #17 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
>     ...
>     #250 0x20c622b in d_bare_function_type binutils-gdb/libiberty/./cp-demangle.c:2932:21
>     #251 0x209f2df in d_function_type binutils-gdb/libiberty/./cp-demangle.c:2856:9
> 
> SUMMARY: AddressSanitizer: stack-overflow binutils-gdb/libiberty/./cp-demangle.c:2367 in cplus_demangle_type

We do fuzz testing on the 15th OCT commit verison of binutils(dc86962bf15e7b8dfdcebc17d83b9b48be0bd9cb). And we have also confirmed this in the release version 2.31.
Please use the “./c++filt < $POC -t” to reproduce the bug. (Remember to add "-t" option and "<" Symbol)
Comment 1 Cheng Wen 2018-10-17 19:16:51 UTC
I have summarized the different recursive stack frames problem in c++filt.

> This issue (In cp-demangle.c.c)
> recursive stack frames: cplus_demangle_type, d_bare_function_type, d_function_type

I find that many people have reported similar problem, but it has not been completely fixed. For example:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9138
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9996
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12641

> [CVE-2018-9138] (In cplus-dem.c)
> recursive stack frames: demangle_nested_args, demangle_args, do_arg, and do_type
> [CVE-2018-9996] (In cplus-dem.c)
> recursive stack frames: demangle_template_value_parm, demangle_integral_value, and demangle_expression
> [CVE-2018-12641] (In cplus-dem.c)
> recursive stack frames: demangle_arm_hp_template, demangle_class_name, demangle_fund_type, do_type, do_arg, demangle_args, and demangle_nested_args.

In addition, there are still some practical problems that have not been successfully reproduced. For example:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333


I tried to reproduce above problem on different machines. That may be your compilation options mismatch. You can try to use the compiler options that I provided.

> CC=clang LDFLAGS="-ldl" CFLAGS="-DFORTIFY_SOURCE=2 -fstack-protector-all -fsanitize=undefined,address -fno-omit-frame-pointer -g -O0 -Wno-error" ./configure --disable-shared --disable-gdb --disable-libdecnumber --disable-sim --prefix=$PWD/build/
> CC=clang CXX=clang++ CFLAGS="-fsanitize=address -fsanitize-recover=address -ggdb" CXXFLAGS="-fsanitize=address -fsanitize-recover=address -ggdb" LDFLAGS="-fsanitize=address" ./configure --prefix=$PWD/build/

Many of these problems have not been completely fixed. I think this problem may need attention.
Comment 2 Cheng Wen 2018-10-17 19:18:01 UTC
This bug was discovered by NTU Cyber-Security-Lab, for fuzzing research work. If you have any questions, please let me know.
Comment 3 Nick Clifton 2018-12-07 10:34:02 UTC
Author: nickc
Date: Fri Dec  7 10:33:30 2018
New Revision: 266886

URL: https://gcc.gnu.org/viewcvs?rev=266886&root=gcc&view=rev
Log:
Add a recursion limit to libiberty's demangling code.  The limit is enabled by default, but can be disabled via a new demangling option.

include	* demangle.h (DMGL_NO_RECURSE_LIMIT): Define.
        (DEMANGLE_RECURSION_LIMIT): Define

	PR 87681
	PR 87675
	PR 87636
	PR 87350
	PR 87335
libiberty * cp-demangle.h (struct d_info): Add recursion_level field.
	* cp-demangle.c (d_function_type): Add recursion counter.
	If the recursion limit is reached and the check is not disabled,
	then return with a failure result.
	(cplus_demangle_init_info): Initialise the recursion_level field.
        (d_demangle_callback): If the recursion limit is enabled, check
	for a mangled string that is so long that there is not enough
	stack space for the local arrays.
        * cplus-dem.c (struct work): Add recursion_level field.
	(squangle_mop_up): Set the numb and numk fields to zero.
	(work_stuff_copy_to_from): Handle the case where a btypevec or 
	ktypevec field is NULL.
	(demangle_nested_args): Add recursion counter.  If
	the recursion limit is not disabled and reached, return with a
	failure result.

Modified:
    trunk/include/ChangeLog
    trunk/include/demangle.h
    trunk/libiberty/ChangeLog
    trunk/libiberty/cp-demangle.c
    trunk/libiberty/cp-demangle.h
    trunk/libiberty/cplus-dem.c
Comment 4 Nick Clifton 2018-12-07 12:48:35 UTC
Fixed by commit 266886.