From ${URL} : A use-after-free vulnerability in rpcbind causing remotely triggerable crash was found. Rpcbind crashes in svc_dodestroy when trying to free a corrupted xprt->xp_netid pointer, which contains a sockaddr_in. Here's how it happens (as explained in http://www.spinics.net/lists/linux-nfs/msg53045.html ) : - A PMAP_CALLIT call comes in on IPv4 UDP - rpcbind duplicates the caller's address to a netbuf and stores it in FINFO[0].caller_addr. caller_addr->buf now points to a memory region A with a size of 16 bytes - rpcbind forwards the call to the local service, receives a reply - when processing the reply, it does this in xprt_set_caller: xprt->xp_rtaddr = *FINFO[0].caller_addr where xprt is the UDP transport on which it received the PMAP_CALLIT request. It sends out the reply, and then frees the netbuf caller_addr and caller_addr.buf. However, it does not clear xp_rtaddr, so xp_rtaddr.buf now refers to memory region A, which is free. - When the next call comes in on the UDP/IPv4 socket, svc_dg_recv will be called, which will set xp_rtaddr to the client's address. It will reuse the buffer inside xp_rtaddr, ie it will write a sockaddr_in to region A. So, this explains how memory gets corrupted. Here's why that eventually lead to a crash in svc_dodestroy. Some time down the road, an incoming TCP connection is accepted, allocating a fresh SVCXPRT. The memory region A is inside the new SVCXPRT - While processing the TCP call, another UDP call comes in, again overwriting region A with the client's address - TCP client closes connection. In svc_destroy, we now trip over the garbage left in region A CVE assignment: http://seclists.org/oss-sec/2015/q3/566 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
fix is in rpcbind-0.2.3-r1 which may go stable at any time http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=de6d02b6cf69bec8e91b7e7e3b4a083f8b13b822
amd64 stable
x86 stable
ppc stable
sparc stable
Stable for HPPA PPC64.
arm stable
alpha stable
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
Arches, Thank you for your work. GLSA Vote: Yes New GLSA Request filed. Maintainer(s), please drop the vulnerable version(s).
Maintainer(s), please drop the vulnerable version(s).
@Maintainer(s), please cleanup.
Dependencies check out... may security please clean?
Can this not be cleaned for some reason?
This issue was resolved and addressed in GLSA 201611-17 at https://security.gentoo.org/glsa/201611-17 by GLSA coordinator Aaron Bauman (b-man).
