Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 560990 (CVE-2015-7236)

Summary: <net-nds/rpcbind-0.2.3-r1: Use-after-free vulnerability in PMAP_CALLIT (CVE-2015-7236)
Product: Gentoo Security Reporter: Agostino Sarubbo <ago>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: minor CC: base-system, net-fs
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1264345
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1264345
Whiteboard: B3 [glsa cve cleanup+]
Package list:
Runtime testing required: ---

Description Agostino Sarubbo gentoo-dev 2015-09-21 10:21:07 UTC
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.
Comment 1 SpanKY gentoo-dev 2015-11-03 15:08:57 UTC
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
Comment 2 Agostino Sarubbo gentoo-dev 2015-11-03 17:13:05 UTC
amd64 stable
Comment 3 Agostino Sarubbo gentoo-dev 2015-11-03 17:14:15 UTC
x86 stable
Comment 4 Agostino Sarubbo gentoo-dev 2015-11-04 14:27:48 UTC
ppc stable
Comment 5 Agostino Sarubbo gentoo-dev 2015-11-05 10:59:23 UTC
sparc stable
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2015-11-06 04:21:50 UTC
Stable for HPPA PPC64.
Comment 7 Markus Meier gentoo-dev 2015-11-14 16:48:26 UTC
arm stable
Comment 8 Matt Turner gentoo-dev 2015-11-15 18:27:51 UTC
alpha stable
Comment 9 Agostino Sarubbo gentoo-dev 2015-11-18 09:33:59 UTC
ia64 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 10 Yury German Gentoo Infrastructure gentoo-dev 2015-12-23 23:22:28 UTC
Arches, Thank you for your work.

GLSA Vote: Yes
New GLSA Request filed.

Maintainer(s), please drop the vulnerable version(s).
Comment 11 Yury German Gentoo Infrastructure gentoo-dev 2016-02-25 08:30:32 UTC
Maintainer(s), please drop the vulnerable version(s).
Comment 12 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-06-11 11:17:48 UTC
@Maintainer(s), please cleanup.
Comment 13 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-07-05 11:53:06 UTC
Dependencies check out... may security please clean?
Comment 14 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-11-11 07:52:37 UTC
Can this not be cleaned for some reason?
Comment 15 GLSAMaker/CVETool Bot gentoo-dev 2016-11-22 11:40:55 UTC
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).