This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- From: Nick Clifton <nickc at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Ian Lance Taylor <iant at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Pedro Alves <palves at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, sgayou at redhat dot com, Tom Tromey <tom at tromey dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, Jason Merrill <jason at redhat dot com>
- Date: Mon, 10 Dec 2018 15:26:18 +0000
- Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536
- References: <736e8303-b724-f96d-54f5-46bff99fa34d@redhat.com> <57d33aa7-4e37-a09c-4bdc-974b5f654d33@redhat.com> <c7c959ca-b8bf-bd3e-a65d-bb274a3118d3@redhat.com> <fca558b7-9ed3-76d0-176c-03f64790e3f1@redhat.com> <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <CAKOQZ8y=B6beozokJ2tdAAkVDVue08ogehMP7TAXvrPzdz9MuQ@mail.gmail.com> <CAMe9rOomd2E3C03CxTXyTRkq6HG32OX+rbMPS3y6dcEWmwaMYg@mail.gmail.com> <CAMe9rOokMpaAUFk0rcYTTUQTQhEMn-VQetXfiDTDXYdTXZEJTA@mail.gmail.com> <alpine.LSU.2.21.1812101442470.5354@wotan.suse.de> <9e739bbc-38a2-c3b1-3b2b-f8de4b755d47@redhat.com> <20181210151846.GB12380@tucnak>
Hi Jakub,
>> My current suggestion
>> is to raise the limit to 2048, which allows the libiberty patch to
>> pass. But do you have a feel for how much is a realistic limit ?
>
> For recursion limit I think that is fine.
> For just stack size limit, I think it is extremely small.
> I see that in the function it allocates on 64-bit 24 bytes times
> num_comps using alloca, so 48 bytes per character in the mangled name,
> and a pointer for each character in the mangled name.
> That is 112KB per 2048 bytes long mangled name.
>
> Dunno how much stack can we expect to be usable.
Currently the patched libiberty uses the DEMANGLE_RECURSION_LIMIT value
in two ways. The first is as a limit on the number of levels of recursion
of specific functions inside the demangler. The second is as a check on
the number of component structures that will be allocated on the stack.
(See cp-demangle.c:d_demangle_callback). One of the CVEs that I was checking
was triggering stack exhaustion this way, which is why I added the check.
There is at least one other function where a similar stack allocation
happens (cplus_demangle_print_callback) but I was not sure if this could
be triggered with the other limits in place, and I did not have a reproducer
that touched it, so I left it alone.
Cheers
Nick