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

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

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
01/05/2024
Última modificación:
19/12/2024

Descripción

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: ubifs_symlink: corrige la fuga de memleak de inodo->i_link en la ruta de error Para el manejo de errores en la ruta en ubifs_symlink(), el inodo se marcará como incorrecto primero y luego se invocará iput(). Si inode->i_link se inicializa mediante fscrypt_encrypt_symlink() en el escenario de cifrado, inode->i_link no será liberado por la cadena de llamadas ubifs_free_inode -> fscrypt_free_inode en la ruta de manejo de errores, porque make_bad_inode() ha cambiado 'inode->i_mode' como 'S_IFREG '. El siguiente kmemleak es fácil de reproducir inyectando un error en ubifs_jnl_update() al realizar un enlace simbólico en un escenario de cifrado: objeto sin referencia 0xffff888103da3d98 (tamaño 8): comm "ln", pid 1692, jiffies 4294914701 (edad 12.045 s) backtrace: kmemdup+0x32/ 0x70 __fscrypt_encrypt_symlink+0xed/0x1c0 ubifs_symlink+0x210/0x300 [ubifs] vfs_symlink+0x216/0x360 do_symlinkat+0x11a/0x190 do_syscall_64+0x3b/0xe0 Hay dos formas de solucionarlo: 1. Eliminar make_bad _inode() en la ruta de manejo de errores. Podemos hacer eso porque ubifs_evict_inode() realizará los mismos procesos para el inodo de enlace simbólico bueno y el inodo de enlace simbólico incorrecto, para inodo->i_nlink la verificación es antes de is_bad_inode(). 2. Libere inodo->i_link antes de marcar el inodo como incorrecto. Se elige el método 2, creo que tiene menos influencia, personalmente.

Impacto