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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1
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.