Re: [PATCH] resolv/res_query: Add note indicating that alloca usage is safe.

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 14/09/23 12:04, Joe Simmons-Talbott wrote:
> Ping.
> 
> On Mon, Aug 28, 2023 at 10:58:25AM -0400, Joe Simmons-Talbott via Libc-alpha wrote:
>> On Mon, Aug 28, 2023 at 10:50:21AM -0300, Adhemerval Zanella Netto wrote:
>>>
>>>
>>> On 05/07/23 15:13, Joe Simmons-Talbott via Libc-alpha wrote:
>>>> The buffer size is small (< 1024) and fixed sized so alloca is safe
>>>> here.
>>>> ---
>>>>  resolv/res_query.c | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/resolv/res_query.c b/resolv/res_query.c
>>>> index 049de91b95..0e0e7be624 100644
>>>> --- a/resolv/res_query.c
>>>> +++ b/resolv/res_query.c
>>>> @@ -117,6 +117,7 @@ __res_context_query (struct resolv_context *ctx, const char *name,
>>>>  	int n, use_malloc = 0;
>>>>  
>>>>  	size_t bufsize = (type == T_QUERY_A_AND_AAAA ? 2 : 1) * QUERYSIZE;
>>>> +	/* alloca is safe here since bufsize < 1024 and fixed sized. */
>>>>  	u_char *buf = alloca (bufsize);
>>>
>>> The bufsize on current Linux build is:
>>>
>>>    size_t bufsize = (type == 439963904 ? 2 : 1) * (12 + 4 + 255 + 1);
>>>
>>> So with upper bound as 544 (2 * (12 + 4 + 255 + 1)).  However, it might
>>> increase to 2 * PACKETSIZE later with malloc.  This is exactly the scenarion
>>> scratch_buffer was created, so maybe we should use it.  Below a complete
>>> untested patch:
>>
>> Thanks for the patch.  I've tested it with 'make check' on
>> x86_64-linux-gnu.  I'm not sure how to handle this and don't feel
>> comfortable submitting it on your behalf or as my own work but am happy
>> to give a Reviewed-by once there's a commit message.

I had forgotten about this, I will send a proper patch.