Page MenuHomeFreeBSD

rpcsec_gss.c: Avoid panics in clnt_nl_call
ClosedPublic

Authored by rmacklem on Jun 28 2025, 11:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 11:21 PM
Unknown Object (File)
Fri, Oct 10, 11:21 PM
Unknown Object (File)
Fri, Oct 10, 11:21 PM
Unknown Object (File)
Fri, Oct 10, 5:03 PM
Unknown Object (File)
Sep 11 2025, 5:50 AM
Unknown Object (File)
Sep 11 2025, 5:14 AM
Unknown Object (File)
Aug 18 2025, 10:08 AM
Unknown Object (File)
Aug 10 2025, 10:02 PM
Subscribers

Details

Summary

When rpc_gss_init() calls gssd upcall functions like
gssd_import_name(), clnt_nl_call() gets calls.
clnt_nl_call() requires that the currect vnet be set up.
The calling sequence looks something like:
rpc_gss_init()->gssd_import_name()->gssd_import_name_1()->clnt_call_private()->clnt_nl_call()
(The call to rpc_gss_init() can happen from various places,
such as nfs_getauth() and clnt_vc_call().)

rpc_gss_init() does not know what socket is being
used for NFS client->server RPCs and may be called
from various places when any VOP_xxx()->RPC call
is made. As such, the calling thread might be running
within a jail. However, the gssd upcalls for the NFS
client must always be done to the gssd running outside
of any jails.

This patch sets the CURVNET to vnet0 in rpc_gss_init()
to fix the problem, since that is the vnet that always
should be used.

Test Plan

Without the patch a panic can be generated by doing
a NFS mount with the options "nfsv4,syskrb5,sec=krb5i"
against a NFS server that is not working correctly for
Kerberized mounts because there is no KDC. (The machine
I was running a KDC on has a HDD failure and I have not
yet set up another KDC.)

With this patch, no panic occurs.

It does take some fiddling to reproduce the panic, since
NFS mounting is always done with CURVNET set to vnet0.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable