SUNRPC: Fix svcauth_gss_proxy_init()
authorChuck Lever <chuck.lever@oracle.com>
Thu, 24 Oct 2019 13:34:16 +0000 (09:34 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 26 Jan 2020 09:00:59 +0000 (10:00 +0100)
commit7be8c165dc81564705e8e0b72d398ef708f67eaa
tree6a39ca750e513d1987a7470e9ace54bff395360e
parentf8120a689b71dabf356f6120eddd272ca2f0f22f
SUNRPC: Fix svcauth_gss_proxy_init()

commit 5866efa8cbfbadf3905072798e96652faf02dbe8 upstream.

gss_read_proxy_verf() assumes things about the XDR buffer containing
the RPC Call that are not true for buffers generated by
svc_rdma_recv().

RDMA's buffers look more like what the upper layer generates for
sending: head is a kmalloc'd buffer; it does not point to a page
whose contents are contiguous with the first page in the buffers'
page array. The result is that ACCEPT_SEC_CONTEXT via RPC/RDMA has
stopped working on Linux NFS servers that use gssproxy.

This does not affect clients that use only TCP to send their
ACCEPT_SEC_CONTEXT operation (that's all Linux clients). Other
clients, like Solaris NFS clients, send ACCEPT_SEC_CONTEXT on the
same transport as they send all other NFS operations. Such clients
can send ACCEPT_SEC_CONTEXT via RPC/RDMA.

I thought I had found every direct reference in the server RPC code
to the rqstp->rq_pages field.

Bug found at the 2019 Westford NFS bake-a-thon.

Fixes: 3316f0631139 ("svcrdma: Persistently allocate and DMA- ... ")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Bill Baker <bill.baker@oracle.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/sunrpc/auth_gss/svcauth_gss.c