Package: rpcbind / 0.2.0-4.1+deb6u1
Metadata
Package | Version | Patches format |
---|---|---|
rpcbind | 0.2.0-4.1+deb6u1 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
01 usage fix.patch | (download) |
src/rpcbind.c |
4 2 + 2 - 0 ! |
--- |
02 manpages.patch | (download) |
man/rpcbind.8 |
5 2 + 3 - 0 ! |
--- |
03 563971 warmstart error msg.patch | (download) |
src/rpcbind.c |
9 7 + 2 - 0 ! |
--- |
debian changes 0.2.0 4 | (download) |
man/rpcbindinfo.8 |
355 355 + 0 - 0 ! |
upstream changes introduced in version 0.2.0-4 This patch has been created by dpkg-source during the package build. Here's the last changelog entry, hopefully it gives details on why those changes were made: . rpcbind (0.2.0-4) unstable; urgency=low . * -w is the default option * Pass the -w option Closes: 563970 * Enable warm starts Add 03-563971-warmstart-error-msg.patch Closes: 563971 * Enable host name checking Build-depend on libwrap0-dev * Provide portmap . The person named in the Author field signed this changelog entry. |
04 CVE 2015 7235.patch | (download) |
src/rpcb_svc_com.c |
3 2 + 1 - 0 ! |
We have seen occasional reports of a commercial security scanner triggering crashes in rpcbind, but these were fairly elusive. Now we finally got a usable core file showing that rpcbind crashed in svc_dodestroy when trying to free a corrupted xprt->xp_netid pointer. Closer inspection suggested that the pointer variable actually contained a sockaddr_in. Here's how I think the memory corruption happens: - 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 The fix seems to be to make xprt_set_caller copy the caller's address to xprt->xp_rtaddr using __rpc_set_netbuf rather than just overwrite the netbuf. Signed-off-by: Olaf Kirch <okir@xxxxxxx> |
1