Re: [PATCH] Avoid memcpy-from-NULL in apr_brigade_flatten

Ruediger Pluem <[email protected]>
Newsgroups gmane.comp.apache.apr.devel
Message-ID <[email protected]>

On 12/18/23 12:09 PM, Joe Orton wrote:
> On Thu, Dec 14, 2023 at 04:44:47PM -0500, Ben Kallus wrote:
>> memcpy to or from NULL is undefined behavior, even for copies of
>> length 0. See this godbolt link for an example of how this can cause
>> problems: https://gcc.godbolt.org/z/zfvnMMsds
>>
>> This patch avoids calling memcpy for 0-length buckets, so that buckets
>> with NULL data and 0 length don't cause UB when flattened.
>>
>> Addresses this bugzilla report from httpd:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=68278
> 
> Thanks for the patch, this is an interesting find. Can you say what 
> bucket type was hit here - e.g. print b->type->name in gdb from inside 
> apr_brigade_flatten()?
> 
> It looks like metadata bucket types tend to give NULL on read() so I'm 
> guessing that's the case here. It would trip up other apr_brigade_* 
> functions in similar ways, e.g. split_line looks wrong too. You can make 
> a case that ignoring FLUSH is "safe" but it's probably undesirable, and 
> trying to flatten across an EOS is almost certainly wrong.
> 
> So I'm not sure, maybe a better/safer response is to catch metadata 
> buckets and treat them as end-of-brigade or an error rather than 
> zero-length data buckets. apr_brigade_split_boundary has an API 
> condition for that to explicitly return APR_INCOMPLETE.

Also for the sake of compatibility I would only fail if we encounter
at non metadata bucket after a possible EOS bucket.
Any metadata before EOS I would just ignore when flattening.

Regards

Rüdiger
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.