Descripción
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: liberar el stateid, no el stateowner, al reintentar la repetición de seqid_op En nfs4_preprocess_seqid_op(), el stateid se obtiene de nfsd4_lookup_stateid(), que mantiene una referencia sobre el nfs4_stid (sc_count) pero no toma ninguna referencia sobre el stateowner. openlockstateid() simplemente convierte ese stid y tampoco toma ninguna referencia. Cuando nfsd4_cstate_assign_replay() retorna -EAGAIN (el propietario de la repetición se está desmantelando, RP_UNHASHED), no ha tomado una referencia al stateowner en esa ruta. No obstante, el manejo de errores llamaba a nfs4_put_stateowner(stp->st_stateowner), liberando una referencia so_count que la función nunca adquirió, con riesgo de un subdesbordamiento del contador de referencias del stateowner y de un uso después de liberar memoria (use-after-free), mientras se filtraba la referencia sc_count mantenida sobre el stid. La referencia filtrada del stid también puede bloquear un nfsd4_close_open_stateid() concurrente que espera a que sc_count disminuya. Se libera la referencia que realmente se mantiene, la del stid, antes de reintentar. El stateowner permanece activo gracias a la referencia mantenida por el stid. Esto replica la ruta de apertura en nfsd4_process_open1(), donde la liberación equilibra una referencia que esa ruta mantiene explícitamente sobre el stateowner.
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: eec7620800081e27dbf8019ac2e66259f0d5bf6f y anteriores a 69ed78b6b947c9257213164678b4edf17533093b · eec7620800081e27dbf8019ac2e66259f0d5bf6f y anteriores a 00843074d9b84824552c9679d423d29500ca5de0 · eec7620800081e27dbf8019ac2e66259f0d5bf6f y anteriores a f7cb90ddc021747fc9abfd4cf5252d425fd34eec · eec7620800081e27dbf8019ac2e66259f0d5bf6f y anteriores a 5e4627d3513e60accfce9d5f4c7fa95251ef93d6
- Linux Afectadas: 6.10 No afectadas: 6.12.109 · 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/69ed78b6b947c9257213164678b4edf17533093b
- Referencia en git.kernel.orggit.kernel.org/stable/c/00843074d9b84824552c9679d423d29500ca5de0
- Referencia en git.kernel.orggit.kernel.org/stable/c/f7cb90ddc021747fc9abfd4cf5252d425fd34eec
- Referencia en git.kernel.orggit.kernel.org/stable/c/5e4627d3513e60accfce9d5f4c7fa95251ef93d6
Ver el texto original en inglés (CVE.org)
nfsd: drop the stateid, not the stateowner, on seqid_op replay retry
In the Linux kernel, the following vulnerability has been resolved: nfsd: drop the stateid, not the stateowner, on seqid_op replay retry In nfs4_preprocess_seqid_op() the stateid is obtained from nfsd4_lookup_stateid(), which holds a reference on the nfs4_stid (sc_count) but takes no reference on the stateowner. openlockstateid() merely casts that stid and likewise takes no reference. When nfsd4_cstate_assign_replay() returns -EAGAIN (the replay owner is being torn down, RP_UNHASHED) it has not taken a stateowner reference on that path. The error handling nevertheless called nfs4_put_stateowner(stp->st_stateowner), dropping an so_count reference the function never acquired -- risking a stateowner refcount underflow and use-after-free -- while leaking the sc_count reference held on the stid. The leaked stid reference can also stall a concurrent nfsd4_close_open_stateid() waiting for sc_count to drop. Drop the reference actually held -- the stid -- before retrying. The stateowner stays alive through the reference held by the stid. This mirrors the open path in nfsd4_process_open1(), where the put balances a reference that path explicitly holds on the stateowner.