Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidad en kernel de Linux (CVE-2024-26958)

Gravedad CVSS v3.1:
ALTA
Tipo:
CWE-416 Utilización después de liberación
Fecha de publicación:
01/05/2024
Última modificación:
23/12/2024

Descripción

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: corrige UAF en escrituras directas En producción hemos estado recibiendo la siguiente advertencia constantemente ------------[ cortar aquí ]----- ------- refcount_t: desbordamiento insuficiente; use-after-free. ADVERTENCIA: CPU: 17 PID: 1800359 en lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Cola de trabajo: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Llamada Seguimiento: ? __advertir+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0? report_bug+0xcc/0x150? handle_bug+0x3d/0x70? exc_invalid_op+0x16/0x40? asm_exc_invalid_op+0x16/0x20? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] Process_one_work+0x12f/0x4a0 trabajador_thread+0x14e/0x3b0? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 Esto se debe a que estamos completando nfs_direct_request dos veces seguidas. La fuente de esto es cuando tenemos que enviar nuestras solicitudes de confirmación, las procesamos y las enviamos, y luego en la ruta de finalización para las solicitudes de confirmación tenemos if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); Sin embargo, dado que enviamos solicitudes asincrónicas, a veces tenemos una que se completa antes de enviar la siguiente, por lo que terminamos llamando a complete en nfs_direct_request dos veces. El único otro lugar donde usamos nfs_generic_commit_list() es en __nfs_commit_inode, que envuelve esta llamada en nfs_commit_begin(); nfs_commit_end(); Este es un patrón común para este estilo de manejo de finalización, uno que también se repite en el código directo con llamadas get_dreq()/put_dreq() en el lugar donde procesamos eventos, así como en las rutas de finalización. Solucione este problema utilizando el mismo patrón para las solicitudes de confirmación. Antes, con mi estrés de rocksdb de 200 nodos ejecutándose, esta advertencia aparecía cada 10 minutos. Con mi parche, la prueba de esfuerzo ha estado funcionando durante varias horas sin aparecer.

Productos y versiones vulnerables

CPE Desde Hasta
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 5.10.215 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 5.11 (incluyendo) 5.15.154 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 5.16 (incluyendo) 6.1.84 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.2 (incluyendo) 6.6.24 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.7 (incluyendo) 6.7.12 (excluyendo)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* 6.8 (incluyendo) 6.8.3 (excluyendo)
cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*