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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: arregla la ejecución entre evice_inodes() y find_inode()&iput() Hola a todos Recientemente noté un error[1] en btrfs, después de investigarlo y creo que es una ejecución en vfs. Supongamos que hay un inodo (es decir, ino 261) con i_count 1 que es llamado por iput(), y hay un hilo concurrente que llama a generic_shutdown_super(). cpu0: cpu1: iput() // i_count es 1 ->spin_lock(inode) ->dec i_count a 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // por alguna razón[2] ->if (atomic_read(inode->i_count)) continue; // regresar antes // el inodo 261 pasó la verificación anterior // list_lru_add_obj() // y luego programar la salida ->spin_unlock() // nota aquí: el inodo 261 // todavía estaba en la lista sb y la lista hash, // y I_FREEING|I_WILL_FREE no se había establecido btrfs_iget() // después de algunas llamadas de función ->find_inode() // encontró el inodo 261 anterior ->spin_lock(inode) // verificó I_FREEING|I_WILL_FREE // y pasó ->__iget() ->spin_unlock(inode) // programó de regreso ->spin_lock(inode) // verificó los indicadores (I_NEW|I_FREEING|I_WILL_FREE), // pasó y estableció I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count a 0 ->iput_final() ->spin_unlock() ->evict() Ahora, tenemos dos subprocesos expulsando simultáneamente el mismo inodo, lo que puede activar la declaración BUG(inode->i_state & I_CLEAR) tanto dentro de clear_inode() como de iput(). Para corregir el error, vuelva a verificar inode->i_count después de mantener i_lock. Porque en la mayoría de los escenarios, la primera verificación es válida y se puede reducir la sobrecarga de spin_lock(). Si hay algún malentendido, hágamelo saber, gracias. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: La razón podría ser 1. SB_ACTIVE fue eliminado o 2. mapping_shrinkable() devolvió falso cuando reproduje el error.