Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 560990 (CVE-2015-7236) - <net-nds/rpcbind-0.2.3-r1: Use-after-free vulnerability in PMAP_CALLIT (CVE-2015-7236)
Summary: <net-nds/rpcbind-0.2.3-r1: Use-after-free vulnerability in PMAP_CALLIT (CVE-2...
Alias: CVE-2015-7236
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [glsa cve cleanup+]
Depends on:
Reported: 2015-09-21 10:21 UTC by Agostino Sarubbo
Modified: 2016-11-22 11:40 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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 ) :

 - 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
   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

 - 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:

@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
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 (RETIRED) gentoo-dev 2016-06-11 11:17:48 UTC
@Maintainer(s), please cleanup.
Comment 13 Aaron Bauman (RETIRED) gentoo-dev 2016-07-05 11:53:06 UTC
Dependencies check out... may security please clean?
Comment 14 Aaron Bauman (RETIRED) gentoo-dev 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
by GLSA coordinator Aaron Bauman (b-man).