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.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.caller_addr
where xprt is the UDP transport on which it received the
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
Created attachment 1074748 [details]
Created rpcbind tracking bugs for this issue:
Affects: fedora-all [bug 1264351]
Created attachment 1074949 [details]
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 6
Via RHSA-2016:0005 https://rhn.redhat.com/errata/RHSA-2016-0005.html
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):