CVE-2026-89784 in Linux
Sumário
de VulDB • 16/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
SUNRPC: verificar o valor de retorno de rpc_sockaddr2uaddr() em rpcb_register_inet4/6
rpcb_register_inet4() e rpcb_register_inet6() armazenam o resultado de rpc_sockaddr2uaddr() em map->r_addr sem verificá-lo quanto a NULL. rpc_sockaddr2uaddr() retorna NULL quando sua chamada final a kstrdup() falha, e o valor NULL não verificado é então propagado para o caminho síncrono de codificação RPCBPROC_SET: rpcb_register_call() -> rpc_call_sync() -> rpcb_enc_getaddr() -> encode_rpcb_string(), cuja primeira instrução é strlen(string), que faz dereference em NULL e causa um kernel oops.
A falha pode ser reproduzida com failslab na versão 6.12; com KASAN, a derefereência de NULL se manifesta como uma falha no shadow do endereço zero:
Oops: general protection fault, provavelmente para endereço não-canônico 0xdffffc0000000000 [#1] PREEMPT SMP KASAN
RIP: 0010:strlen (lib/string.c:409) Call Trace: encode_rpcb_string (net/sunrpc/rpcb_clnt.c:890) rpcb_enc_getaddr (net/sunrpc/rpcb_clnt.c:910) rpcauth_wrap_req_encode (net/sunrpc/auth.c:745) call_encode (net/sunrpc/clnt.c:1966) __rpc_execute (net/sunrpc/sched.c:952) rpc_run_task (net/sunrpc/clnt.c:1243) rpc_call_sync (net/sunrpc/clnt.c:1272) rpcb_v4_register (net/sunrpc/rpcb_clnt.c:500) svc_generic_rpcbind_set nfsd_rpcbind_set svc_register svc_setup_socket svc_addsock write_ports nfsctl_transaction_write vfs_write
A falha é acessível quando um serviço RPC no kernel (nfsd, lockd, nfs-callback) se registra com o rpcbind local sob pressão de memória suficiente para que a pequena alocação GFP_KERNEL via kstrdup() em rpc_sockaddr2uaddr() falhe. O caminho assíncrono getport já lida corretamente com esse exato modo de falha retornando -ENOMEM; apenas os dois auxiliares de registro omitem essa verificação.
Espelhar esse tratamento: abortar a operação retornando -ENOMEM quando rpc_sockaddr2uaddr() retornar NULL, antes que o endereço seja alimentado no codificador.
Once again VulDB remains the best source for vulnerability data.