Reported by Marcus Meissner here: http://openwall.com/lists/oss-security/2017/05/05/1 “ We also saw glibc affected. https://bugzilla.suse.com/show_bug.cgi?id=1037559#c7 That said, your reproducer allocates virtual memory, and on systems with overcommit there is only neglible impact on overall memory pressure. The rpc service will however likely crash at some point though when there is no virtual address space left for it. ”
CVE-2017-8779 is related, but may not have been assigned to this flaw specifically.
Patch posted: https://sourceware.org/ml/libc-alpha/2017-05/msg00105.html
I think the caller is supposed to always call xdr_string with XDR_FREE, even if XDR_DECODE failed. That needs a test case to demonstrate that this isn't the case here.
(In reply to Andreas Schwab from comment #3) > I think the caller is supposed to always call xdr_string with XDR_FREE, even > if XDR_DECODE failed. That needs a test case to demonstrate that this isn't > the case here. Except when the caller supplied the buffer, I assume. Should we fix this as a non-security QoI issue?
Note that other XDR functions like xdr_array and xdr_reference have the same issue.
I have verified that this patch for rpcbind fixes the issue: Index: rpcbind-0.2.3/src/rpcb_svc.c =================================================================== --- rpcbind-0.2.3.orig/src/rpcb_svc.c +++ rpcbind-0.2.3/src/rpcb_svc.c @@ -166,7 +166,7 @@ rpcb_service_3(struct svc_req *rqstp, SV svcerr_decode(transp); if (debugging) (void) xlog(LOG_DEBUG, "rpcbind: could not decode"); - return; + goto done; } if (rqstp->rq_proc == RPCBPROC_SET Index: rpcbind-0.2.3/src/rpcb_svc_4.c =================================================================== --- rpcbind-0.2.3.orig/src/rpcb_svc_4.c +++ rpcbind-0.2.3/src/rpcb_svc_4.c @@ -220,7 +220,7 @@ rpcb_service_4(struct svc_req *rqstp, SV svcerr_decode(transp); if (debugging) (void) xlog(LOG_DEBUG, "rpcbind: could not decode\n"); - return; + goto done; } if (rqstp->rq_proc == RPCBPROC_SET A similar patch is needed for svc_simple.c.
Based on the libc-alpha discussion here: https://sourceware.org/ml/libc-alpha/2017-05/msg00128.html https://sourceware.org/ml/libc-alpha/2017-05/msg00129.html this an application bug and not a glibc vulnerability.