FreeBSD rpcbind seems to be vulnerable too:
# ruby rpcbomb.rb localhost 100000000
r p c b o m b
DoS exploit for *nix rpcbind/libtirpc.
(c) 2017 Guido Vranken.
Allocated 100000000 bytes at host localhost:111.
Damn it feels good to be a gangster.
All usr.sbin/rpcbind, libc/rpc and kernel sys/rpc are affected.
usr.sbin/rpcbind can be patched from https://github.com/guidovranken/rpcbomb/rpcbind_patch.txt
libc/rpc and sys/rpc can be probably patched more or less directly from https://github.com/guidovranken/rpcbomb/libtirpc_patch.txt
I'd like to point out that the output from rpcbomb.rb proves nothing. It always prints the exact same message, unless it manages to cause rpcbind to crash, in which case it prints "No response from server received." instead; but rpcbind will not crash and will continue to answer the requests you really care about (GETPORT, mostly). The target host will not crash either, because rpcbomb only fills up the target process's address space, not the host's physical memory or swap. My tests resulted in rpcbind growing to 128 TB but otherwise functioning normally. I was unable to provoke a similar bug in nfsd (with a carefully crafted LOOKUP request), but I didn't try very hard, and it would have been very slow.
Also, the rpcbind patch is purely cosmetic. It sets an upper bound on the amount of memory libtirpc will leak, so it slows down the attack but does not prevent it (as long as the attacker adjusts numBytes so the packet isn't rejected until after the memory has been allocated). The other patch is mostly just more of the same; the only part you really need is the xdr.c bit, with a few improvements.
So maybe this is the right direction?
rpcbind doesn't call svc_freeargs() in the case of svc_getargs() failure,
so buffer for string is not released.
And another conclusion:
Created attachment 182540 [details]
patch for usr.sbin/rpcbind
I can confirm, that with this patch rpcbind VM size doesn't increase after rpcbomb.
The other files (pmap_svc.c, rpcb_svc_com.c) that are patched in the Linux case, are probably not required to patch at all, as their rpc arguments are not allocated and cannot leak.
Fixed in r319369.