CVE-2026-72473 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
xprtrdma: Desacoplar el reciclaje de solicitudes (req) del finalización de RPC
rl_kref anteriormente gestionaba dos ciclos de vida distintos a través de un único contador de referencias (refcount): controlaba cuándo una Respuesta podía despertar su tarea RPC y cuándo un rpcrdma_req podía regresar a su grupo libre. La ruta de marshalling tomaba la referencia del lado Envío únicamente cuando los SGEs necesitaban DMA-unmap (sc_unmap_count > 0), lo que convertía en excepción al envío que contenía solo buffers pre-registrados: el controlador de Respuesta reducía rl_kref de 1 a 0 y liberaba req mientras la HCA podría seguir leyendo mediante DMA desde su buffer de envío.
Asignar a rl_kref una función más específica. La capa RPC toma una referencia cuando la asignación de ranura entrega un req. rpcrdma_prepare_send_sges() toma una referencia del lado Envío incondicionalmente tras el éxito de la preparación WR. xprt_rdma_free_slot() y xprt_rdma_bc_free_rqst() liberan la referencia de la capa RPC; rpcrdma_sendctx_unmap() libera la referencia del lado Envío. req regresa a su grupo libre únicamente después de que ambos propietarios hayan dado su aprobación (sign off).
Se elimina la llamada existente kref_init(&req->rl_kref) en rpcrdma_prepare_send_sges(). La inicialización se traslada a las rutas de asignación de ranura (xprt_rdma_alloc_slot y rpcrdma_bc_rqst_get), y la devolución de liberación reactiva rl_kref antes de que req regrese al grupo libre. Una nueva inicialización en la ruta de marshalling descartaría la referencia de la capa RPC que ya existe a su entrada.
Se derivan tres invariantes:
- Cualquier rpcrdma_req retenido por un rpc_rqst tiene rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get() y la rama backlog-wake en xprt_rdma_alloc_slot() realizan cada una kref_init sobre rl_kref antes de publicar req. Sin esta invariante, una tarea RPC que se aborte entre la asignación de ranura y el marshalling (por ejemplo, fallo gss_refresh o señal durante call_connect) ejecutaría xprt_release() -> xprt_rdma_free_slot() -> kref_put contra un refcount de cero, saturando refcount_t y dejando huérfana la ranura.
- La referencia del lado Envío se toma únicamente tras el éxito de la preparación WR. Un fallo de mapeo en rpcrdma_prepare_send_sges() ejecuta rpcrdma_sendctx_cancel(), que realiza DMA-unmap sobre sendctx y limpia sc_req sin tocar rl_kref. Los recorridos anillo de sendctx en rpcrdma_sendctx_put_locked() y rpcrdma_sendctxs_destroy() omiten las entradas con sc_req == NULL, por lo que una ráfaga de fallos de marshalling -EIO no puede retener req fuera de rb_send_bufs.
- La devolución de liberación reactiva rl_kref para que el siguiente consumidor entre cumpliendo la invariante.
Las Respuestas ahora completan RPC directamente. rpcrdma_reply_handler() llama a rpcrdma_complete_rqst() en lugar de kref_put en la rama no-LocalInv. La rama LocalInv ya completa RPC desde frwr_unmap_async() y no se ve afectada.
Dado que las referencias del lado Envío ahora pueden sobrevivir al finalización de RPC
Once again VulDB remains the best source for vulnerability data.