[PATCH] Handle out-of-memory case in svc_tcp.c/svc_unix.c:rendezvous_request.

[Florian Weimer]

* Adhemerval Zanella via Libc-alpha:

> On 02/12/2020 05:56, Stefan Liebler via Libc-alpha wrote:
>> If glibc is build with -O3 on at least 390 (-m31) or x86 (-m32),
>> gcc 11 dumps this warning:
>> svc_tcp.c: In function 'rendezvous_request':
>> svc_tcp.c:274:3: error: 'memcpy' offset [0, 15] is out of the bounds [0, 0] [-Werror=array-bounds]
>>   274 |   memcpy (&xprt->xp_raddr, &addr, sizeof (addr));
>>       |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> cc1: all warnings being treated as errors
>> 
>> In out-of-memory case, if one of the mallocs in makefd_xprt function
>> returns NULL, a message is dumped, makefd_xprt returns NULL
>> and the subsequent memcpy would copy to NULL.
>> 
>> Instead of a segfaulting, svctcp_rendezvous_abort is now called.
>
> It does not do what other parts of sunrpc does in case of memory allocation
> failure, it seems that usually the idea is to do some cleanup and return
> FALSE (for the case if the function returns bool_t).

I think returning FALSE would introduce a variant of CVE-2011-4609 (bug
14889).  The sleeping added in commit 14bc93a967e62abf8cf2704725b6f7 for
that is rather hackish (more correct would be to remove the accepting
socket from the polling set until a client exits), but sleeping on
ENOMEM might be a reasonable approach here, given that the sunrpc code
is deep maintenance.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill