RFA/RFC: Add stack recursion limit to libiberty's demangler

Ian Lance Taylor ian@airs.com
Fri Nov 30 14:57:00 GMT 2018


Michael Matz <matz@suse.de> writes:

> On Fri, 30 Nov 2018, Nick Clifton wrote:
>
>> Not without modifying the current demangling interface.  The problem is 
>> that the context structure is created for each invocation of a 
>> demangling function (from outside the library), and no state is 
>> preserved across demangling calls.  Thus in order to have a recursion 
>> limit which is configurable by the caller, you either need to have a 
>> global variable or else extend the demangling interface to include a 
>> recursion limit parameter.
>> 
>> I did consider just having a fixed limit, that the user cannot change, 
>> but I thought that this might be rejected by reviewers.  (On the grounds 
>> that different limits are appropriate to different execution 
>> environments). Note - enabling or disabling the recursion limit is 
>> controlled by a separate feature of the proposed patch, ie the new 
>> DMGL_RECURSE_LIMIT flag in the options field of the cplus_demangleXXX() 
>> functions.  But there is not enough room in the options field to also 
>> include a recursion limit value.
>
> Or we decide to not ignore this part of the GNU coding standard ...
>
>> 4.2 Writing Robust Programs
>>  
>> Avoid arbitrary limits on the length or number of any data structure, 
>> including file names, lines, files, and symbols, by allocating all data 
>> structures dynamically. In most Unix utilities, “long lines are silently 
>> truncated”. This is not acceptable in a GNU utility.
>
> ... just because script kiddies do mindless fuzzing work.  I realize that 
> you didn't implement a fixed limit, but IMHO it's bordering with that.

That section is "Writing Robust Programs."  Robustness guarantees have
to be different for utilities and servers.  A robust server doesn't
crash because of arbitrary user input, but there are servers that
demangle names that are provided by the user.  So we need two modes for
the demangler: one that takes anything and sometimes crashes, for
utilities like c++filt, and one that doesn't crash, for servers.  And it
seems like that is what Nick is suggesting.

Ian



More information about the Binutils mailing list