Re: [PATCH 00/25] Remove extend_alloca [BZ #18023]

[Florian Weimer <fweimer at redhat dot com>]

On 03/03/2015 03:23 PM, Joseph Myers wrote:
> On Mon, 2 Mar 2015, Florian Weimer wrote:
> 
>> This series of patches removes extend_alloca.
>>
>> I tried to split up the patches by subsystems, and separate patches
>> which address different coding patterns.
> 
> Did any of the cases changed previously involve unbounded stack usage for 
> any supported glibc configuration (rather than simply more usage than 
> intended)?  If so, they should have their own bugs filed in Bugzilla, as 
> bugs that were user-visible in a release.

I don't know how large a NSS result can get in practice.  If it can be
so large that it does not fit on a stack, there might be a problem.
Maybe this is even database-dependent (struct hostent requirements seem
larger than struct pwent, and struct group is probably somewhere between).

The results would have to be really huge (multiple megabytes).  I don't
think anyone runs nscd with 128K stacks or something like that.

>> Most extend_alloca uses were converted to a set of helper functions
>> around the new type struct scratch_buffer.  This facility uses a
>> fixed-size stack allocation with malloc fallback if the requested buffer
>> size exceeds the stack allocation.
> 
> Do all these cases (or other cases using malloc now) already have safety 
> annotations in the manual that indicate that they may call malloc?

I was careful not to introduce malloc in contexts that did not use it
before (for example, the affinity function).  Not all functions used
malloc fallback for the buffer or other heap allocations, but those
calls where inside NSS or nscd, which I consider a malloc-ing context.

Both vfprintf and vfscanf already used malloc (even with
innocently-looking format strings), so my change does not make matters
worse there.

> If not, the safety annotations need updating, and if making some function 
> newly call malloc, this needs to be OK with any POSIX requirements on 
> safety of that function.

As far as I can tell, no such changes are needed.

-- 
Florian Weimer / Red Hat Product Security