CVE-2026-89784: SUNRPC: check rpc_sockaddr2uaddr() return value in rpcb_register_inet4/6
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: check rpcsockaddr2uaddr() return value in rpcbregisterinet4/6
rpcbregisterinet4() and rpcbregisterinet6() store the result of rpcsockaddr2uaddr() into map->raddr without checking it for NULL. rpcsockaddr2uaddr() returns NULL when its final kstrdup() fails, and the unchecked NULL is then carried into the synchronous RPCBPROCSET encode path: rpcbregistercall() -> rpccallsync() -> rpcbencgetaddr() -> encoderpcbstring(), whose first statement is strlen(string), dereferencing NULL and oopsing the kernel.
The crash reproduces under failslab on v6.12; with KASAN the NULL dereference surfaces as a fault on the shadow of address zero:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000 [#1] PREEMPT SMP KASAN RIP: 0010:strlen (lib/string.c:409) Call Trace: encoderpcbstring (net/sunrpc/rpcbclnt.c:890) rpcbencgetaddr (net/sunrpc/rpcbclnt.c:910) rpcauthwrapreqencode (net/sunrpc/auth.c:745) callencode (net/sunrpc/clnt.c:1966) rpcexecute (net/sunrpc/sched.c:952) rpcruntask (net/sunrpc/clnt.c:1243) rpccallsync (net/sunrpc/clnt.c:1272) rpcbv4register (net/sunrpc/rpcbclnt.c:500) svcgenericrpcbindset nfsdrpcbindset svcregister svcsetupsocket svcaddsock writeports nfsctltransactionwrite vfswrite
The crash is reachable when an in-kernel RPC service (nfsd, lockd, nfs-callback) registers with the local rpcbind under enough memory pressure for the small GFPKERNEL kstrdup() in rpcsockaddr2uaddr() to fail. The asynchronous getport path already handles this exact failure mode by returning -ENOMEM; only the two register helpers omit the check.
Mirror that handling: bail out with -ENOMEM when rpcsockaddr2uaddr() returns NULL, before the address is fed into the encoder.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the kernel crash?
The failure requires rpc_sockaddr2uaddr() to return NULL because its final kstrdup() allocation fails while rpcb_register_inet4() or rpcb_register_inet6() is registering with RPCBPROC_SET. The unchecked NULL then reaches encode_rpcb_string(), which calls strlen() on it and oopses the kernel.
Is this issue remotely exploitable based on the available information?
The provided information describes an allocation-failure path during local kernel SUNRPC processing and demonstrates reproduction with failslab. It does not establish a remote trigger or identify an attacker-controlled input that can force the allocation failure.
How can I determine whether a system has encountered this issue?
Look for a kernel oops with strlen in the call trace, followed by encode_rpcb_string, rpcb_enc_getaddr, rpc_call_sync, and RPC bind registration functions. With KASAN, the report may appear as a general protection fault involving the shadow of address zero.
What is the immediate mitigation if an updated kernel cannot be deployed?
The supplied data does not provide a configuration workaround. The described trigger depends on a memory-allocation failure during SUNRPC RPC bind registration, so avoid relying on unverified mitigations and plan to deploy a kernel containing the referenced fix.