rpcbind: Fix a coredump that occurs when rpcinfo is done

[rmacklem]

Summary

Commit c5d671b added netlink support to
server side rpcbind. However it did not add
a case for AF_NETLINK to __rpc_taddr2uaddr_af().
(Reported as PR#289625.)

As such, without this patch the r_addr field of the
netlink rbllist is NULL, which causes a crash in
svc_sendreply() for a Dump query (what rpcinfo
does).

This patch fixes the crash, but I have no idea what
the correct string for a netlink address should be?

Test Plan

Tested by linking rpcbind to a patched rpc_generic.c.

[glebius]

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

[rmacklem]

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

Yea, it's old Sun RPC code written back when ISO TP4 was going to
replace TCP very soon.

Before the netlink patch, rpcinfo generated:

program version netid     address                service    owner
 100000    4    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    3    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    2    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    4    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    3    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    2    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    4    tcp6      ::.0.111               rpcbind    superuser
 100000    3    tcp6      ::.0.111               rpcbind    superuser
 100000    4    udp6      ::.0.111               rpcbind    superuser
 100000    3    udp6      ::.0.111               rpcbind    superuser
 100000    4    local     /var/run/rpcbind.sock  rpcbind    superuser
 100000    3    local     /var/run/rpcbind.sock  rpcbind    superuser
 100000    2    local     /var/run/rpcbind.sock  rpcbind    superuser

Now, with this patch:

program version netid     address                service    owner
 100000    4    netlink   netlink                rpcbind    superuser
 100000    3    netlink   netlink                rpcbind    superuser
 100000    4    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    3    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    2    tcp       0.0.0.0.0.111          rpcbind    superuser
 100000    4    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    3    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    2    udp       0.0.0.0.0.111          rpcbind    superuser
 100000    4    tcp6      ::.0.111               rpcbind    superuser
 100000    3    tcp6      ::.0.111               rpcbind    superuser
 100000    4    udp6      ::.0.111               rpcbind    superuser
 100000    3    udp6      ::.0.111               rpcbind    superuser
 100000    4    local     /var/run/rpcbind.sock  rpcbind    superuser
 100000    3    local     /var/run/rpcbind.sock  rpcbind    superuser
 100000    2    local     /var/run/rpcbind.sock  rpcbind    superuser

So, this patch adds the two netlink entries at the top.
I'm not sure they mean anything here, so I think it
might be better to change the patch so it just skips
over them.

What do you think?

[rmacklem]

In D52651#1203905, @glebius wrote:

What code does call into this function with netlink argument? IMHO, this transport layer abstraction of RPC is a big code bloat where most of the code is never executed. Of course a crash if it happens needs to be fixed.

Even if you think rpcinfo should not get the
"netlink" entries, the proposed patch (with
some string for address, I don't care what it is)
is needed, since callers do not expect r_addr to be NULL.

[rmacklem]

Just fyi. Unless I hear otherwise I am going to commit
this patch Monday, so that it can be MFC'd to stable/15.
It stops rpcbind from crashing. If others don't like the
choice of address string for netlink, that can be changed
later.

[glebius]

I see, in

lib/libc/rpc/rpc_generic.c

625

The result would be the same in case of rpcbind. It already has "netlink" hardcoded there.

[rmacklem]

lib/libc/rpc/rpc_generic.c

625

So, tell me what string you want here
today, since I am committing it tomorrow.
I don't care what it is.

"netlink-local"
"local"
"local-addr"
or ??

[glebius]

lib/libc/rpc/rpc_generic.c

625

No hardcoded string, but treat nbuf->buf as NULL terminated string. See suggested edit above ^^

[glebius]

if (asprintf(&ret, "%s", (char *)nbuf->buf) < 0)

[rmacklem]

lib/libc/rpc/rpc_generic.c

625

Ok. Sorry. I didn't look at the code, just the
comment.

I've changed the patch to do the above.

Thanks.