CVE-2026-72473 in Linuxinformação

Sumário

de VulDB • 15/08/2026

No kernel do Linux, a seguinte vulnerabilidade foi resolvida:

xprtrdma: Desacoplar o reutilização de reqs da conclusão RPC

rl_kref anteriormente atendia dois ciclos de vida distintos por meio de uma única contagem de referência (refcount): ele controlava quando uma Resposta poderia despertar sua tarefa RPC e controlava quando um rpcrdma_req podia retornar a seu pool livre. O caminho de marshalling adquiria a referência do lado Envio apenas quando os SGEs precisavam ser desmapeados via DMA (sc_unmap_count > 0), o que tornava um Envio contendo apenas buffers pré-registrados uma exceção: o manipulador de Resposta decrementava rl_kref de 1 para 0 e liberava o req enquanto a HCA ainda poderia estar lendo via DMA em seu buffer de envio.

Atribua a rl_kref uma função mais restrita. A camada RPC adquire uma referência quando a alocação da slot entrega um req. rpcrdma_prepare_send_sges() adquire uma referência do lado Envio incondicionalmente após o sucesso na preparação da WR (Work Request). xprt_rdma_free_slot() e xprt_rdma_bc_free_rqst() liberam a referência da camada RPC; rpcrdma_sendctx_unmap() libera a referência do lado Envio. O req retorna ao seu pool livre apenas depois que ambos os proprietários assinarem o encerramento (sign off).

A chamada existente kref_init(&req->rl_kref) em rpcrdma_prepare_send_sges() é removida. A inicialização move-se para os caminhos de alocação da slot (xprt_rdma_alloc_slot e rpcrdma_bc_rqst_get), e a função de liberação reativa rl_kref antes que o req retorne ao pool livre. Uma nova inicialização no caminho de marshalling descartaria a referência da camada RPC que já existe na entrada.

Três invariantes seguem:

- Qualquer rpcrdma_req mantido por um rpc_rqst possui rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get() e o ramo de despertar do backlog em xprt_rdma_alloc_slot() inicializam cada um rl_kref com kref_init antes de publicar o req. Sem este invariante, uma tarefa RPC que abortar entre a alocação da slot e o marshalling (falha no gss_refresh ou sinal durante call_connect, por exemplo) acionaria xprt_release() -> xprt_rdma_free_slot() -> kref_put contra um refcount de zero, saturando refcount_t e deixando a slot órfã.

- A referência do lado Envio é adquirida apenas após o sucesso da preparação WR. Uma falha no mapeamento em rpcrdma_prepare_send_sges() executa rpcrdma_sendctx_cancel(), que desmapeia via DMA o sendctx e limpa sc_req sem tocar rl_kref. Os loops de varredura do anel sendctx em rpcrdma_sendctx_put_locked() e rpcrdma_sendctxs_destroy() pulam entradas com sc_req == NULL, portanto uma rajada de falhas de marshalling -EIO não pode impedir reqs nos rb_send_bufs.

- A função de liberação reativa rl_kref para que o próximo consumidor entre satisfazendo o invariante.

As Respostas agora completam a RPC diretamente. rpcrdma_reply_handler() chama rpcrdma_complete_rqst() no lugar do kref_put no ramo não-LocalInv. O ramo LocalInv já completa a RPC de frwr_unmap_async() e não é afetado.

Como as referências do lado Envio podem agora

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Responsável

Linux

Reservar

09/08/2026

Divulgação

15/08/2026

Moderação

aceite

Entrada

VDB-391048

CPE

pronto

EPSS

0.00215

KEV

não

Atividades

baixo

Fontes

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!