Descripción
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: no liberar espacios (slots) de sesión que aún están en uso nfsd4_sequence() puede liberar el mismo slot que está procesando. Cuando el reductor de sesiones ha disminuido se_target_maxslots por debajo de se_fchannel.maxreqs, la ruta de reducción verifica tres condiciones antes de llamar a free_session_slots(): 1. se_target_maxslots < maxreqs (se anunció la reducción) 2. slot->sl_generation == se_slot_gen (el slot está actualizado) 3. seq->maxslots <= se_target_maxslots (el cliente lo reconoce) Sin embargo, seq->slotid nunca se compara con se_target_maxslots. Un cliente que use un slot en el rango [se_target_maxslots, maxreqs) puede cumplir las tres condiciones: su slot tiene la generación actual (establecida por un SEQUENCE previo) y envía sa_highest_slotid <= se_target_maxslots para reconocer la reducción. free_session_slots() libera entonces con kfree todos los slots con índice >= se_target_maxslots, incluido el propio slot del invocador. La función continúa escribiendo sl_seqid, sl_flags y sl_generation, y almacena el puntero colgante en cstate->slot. Posteriormente, nfsd4_store_cache_entry() copia hasta maxresp_cached bytes de la respuesta compuesta en el arreglo sl_data[] liberado, corrompiendo cualquier objeto slab que ocupe ahora esa dirección. Además, a un hilo concurrente que procese SEQUENCE en otro slot de numeración alta se le puede liberar su slot mientras lo usa. NFSD4_SLOT_INUSE se establece bajo nn->client_lock antes de liberar el bloqueo, por lo que cualquier hilo concurrente que haya pasado SEQUENCE tendrá su slot marcado. Sin embargo, free_session_slots() no verifica NFSD4_SLOT_INUSE antes de liberar. Se corrigen ambos problemas: 1. Verificando que el slotid de la solicitud actual esté por debajo del límite de reducción. 2. Revisando los slots del rango que se va a liberar en busca de NFSD4_SLOT_INUSE y aplazando la reducción si alguno está activo.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- Linux Afectadas: fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7 y anteriores a 72d40b103bb03f0124d3a3c8f71a30cbafaf6afa · fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7 y anteriores a b449b134e7762ddf98653a4b1d3e76d2d212ea64 · fc8738c68d0bbf5033dd98b4f63d277ecbd49fd7 y anteriores a f5d22e372f4ac3eb287037a488c29691d52a6330
- Linux Afectadas: 6.14 No afectadas: 6.18.50 · 7.2.4 · 7.3
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en git.kernel.orggit.kernel.org/stable/c/72d40b103bb03f0124d3a3c8f71a30cbafaf6afa
- Referencia en git.kernel.orggit.kernel.org/stable/c/b449b134e7762ddf98653a4b1d3e76d2d212ea64
- Referencia en git.kernel.orggit.kernel.org/stable/c/f5d22e372f4ac3eb287037a488c29691d52a6330
Ver el texto original en inglés (CVE.org)
nfsd: don't free session slots that are still in use
In the Linux kernel, the following vulnerability has been resolved: nfsd: don't free session slots that are still in use nfsd4_sequence() can free the very slot it is currently processing. When the session shrinker has reduced se_target_maxslots below se_fchannel.maxreqs, the shrink path checks three conditions before calling free_session_slots(): 1. se_target_maxslots < maxreqs (shrink was advertised) 2. slot->sl_generation == se_slot_gen (slot is up-to-date) 3. seq->maxslots <= se_target_maxslots (client acknowledges) However, seq->slotid is never checked against se_target_maxslots. A client using a slot in the range [se_target_maxslots, maxreqs) can satisfy all three conditions: its slot has the current generation (set by a prior SEQUENCE), and it sends sa_highest_slotid <= se_target_maxslots to acknowledge the reduction. free_session_slots() then kfrees every slot at index >= se_target_maxslots, including the caller's own slot. The function continues to write sl_seqid, sl_flags, sl_generation, and stores the dangling pointer in cstate->slot. Later, nfsd4_store_cache_entry() copies up to maxresp_cached bytes of the compound reply into the freed sl_data[] array, corrupting whatever slab object now occupies that address. Additionally, a concurrent thread processing SEQUENCE on a different high-numbered slot can have its slot freed out from under it. NFSD4_SLOT_INUSE is set under nn->client_lock before the lock is released, so any concurrent thread past SEQUENCE will have its slot marked. However, free_session_slots() does not check NFSD4_SLOT_INUSE before freeing. Fix both problems by: 1. Checking that the current request's slotid is below the shrink boundary. 2. Scanning slots in the to-be-freed range for NFSD4_SLOT_INUSE and deferring the shrink if any are active.