https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335
--- Comment #11 from Cheng Wen <wcventure at 126 dot com> ---
(In reply to Scott Gayou from comment #10)
> does NOT crash
That depends on your compilation options. Because stack memory is very small,
generally only 1M to 2M. You can debug it with GDB and see the backtrace.
> This looks to be another potentially duplicated CVE.
Unlike several other errors, this error is to call itself. In addition, This
problem was discovered earlier than those CVEs.
> All appear to be the same root cause.
Let's analyze the source code.
struct demangle_component *
cplus_demangle_type (struct d_info *di) {
switch (peek)
{
// ...
case 'F':
ret = d_function_type (di); break;
// ...
case 'P':
ret = d_make_comp (di, DEMANGLE_COMPONENT_POINTER,
cplus_demangle_type (di), NULL);
break;
case 'C':
ret = d_make_comp (di, DEMANGLE_COMPONENT_COMPLEX,
cplus_demangle_type (di), NULL);
break;
case 'G':
ret = d_make_comp (di, DEMANGLE_COMPONENT_IMAGINARY,
cplus_demangle_type (di), NULL);
break;
// ...
}
// ...
}
Intuitively, in some cases, function cplus_demangle_type shows the behavior of
recursive calls. When the function cplus_demangle_type receive character
'P'(The same as 'C' and 'G'), the cplus_demangle_type function making recursive
calls to itself(Line 13, 18, 23). Another situation is that the function
receive character 'F', then there's a recursed stack frame:
cplus_demangle_type, d_bare_function_type, d_function_type(Line 8, 32, 39).
So different stack memory exhaustion can lead to stack memory exhaustion DoS.
That depends on your compilation options. You can use my compilation options.
> 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
If you have any question, please let me know.
