diff options
| author | Stefan Liebler <stli@linux.ibm.com> | 2020-12-04 17:00:27 +0100 |
|---|---|---|
| committer | Stefan Liebler <stli@linux.ibm.com> | 2020-12-10 11:11:20 +0100 |
| commit | 4b2e40a9259fab08161e1c607b06a41e15d543dc (patch) | |
| tree | d9b01ed2133968f280d1a0d950fd7bd232ddd87a /sunrpc/svc_tcp.c | |
| parent | 0d4ed9d40efa84e8dc88e64cf337c8e95af7b045 (diff) | |
| download | glibc-4b2e40a9259fab08161e1c607b06a41e15d543dc.tar.gz | |
Handle out-of-memory case in svc_tcp.c/svc_unix.c:rendezvous_request.
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, we delay a bit (see also __svc_accept_failed
and Bug 14889 (CVE-2011-4609) - svc_run() produces high cpu usage when
accept() fails with EMFILE (CVE-2011-4609).
The same applies to svc_unix.c.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Diffstat (limited to 'sunrpc/svc_tcp.c')
| -rw-r--r-- | sunrpc/svc_tcp.c | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/sunrpc/svc_tcp.c b/sunrpc/svc_tcp.c index efbdd22548..12de60f605 100644 --- a/sunrpc/svc_tcp.c +++ b/sunrpc/svc_tcp.c @@ -271,6 +271,14 @@ again: * make a new transporter (re-uses xprt) */ xprt = makefd_xprt (sock, r->sendsize, r->recvsize); + + /* If we are out of memory, makefd_xprt has already dumped an error. */ + if (xprt == NULL) + { + __svc_wait_on_error (); + return FALSE; + } + memcpy (&xprt->xp_raddr, &addr, sizeof (addr)); xprt->xp_addrlen = len; return FALSE; /* there is never an rpc msg to be processed */ |