"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: fix race between evice_inodes() and find_inode()&iput()\n\nHi, all\n\nRecently I noticed a bug[1] in btrfs, after digged it into\nand I believe it'a race in vfs.\n\nLet's assume there's a inode (ie ino 261) with i_count 1 is\ncalled by iput(), and there's a concurrent thread calling\ngeneric_shutdown_super().\n\ncpu0: cpu1:\niput() // i_count is 1\n ->spin_lock(inode)\n ->dec i_count to 0\n ->iput_final() generic_shutdown_super()\n ->__inode_add_lru() ->evict_inodes()\n // cause some reason[2] ->if (atomic_read(inode->i_count)) continue;\n // return before // inode 261 passed the above check\n // list_lru_add_obj() // and then schedule out\n ->spin_unlock()\n// note here: the inode 261\n// was still at sb list and hash list,\n// and I_FREEING|I_WILL_FREE was not been set\n\nbtrfs_iget()\n // after some function calls\n ->find_inode()\n // found the above inode 261\n ->spin_lock(inode)\n // check I_FREEING|I_WILL_FREE\n // and passed\n ->__iget()\n ->spin_unlock(inode) // schedule back\n ->spin_lock(inode)\n // check (I_NEW|I_FREEING|I_WILL_FREE) flags,\n // passed and set I_FREEING\niput() ->spin_unlock(inode)\n ->spin_lock(inode)\t\t\t ->evict()\n // dec i_count to 0\n ->iput_final()\n ->spin_unlock()\n ->evict()\n\nNow, we have two threads simultaneously evicting\nthe same inode, which may trigger the BUG(inode->i_state & I_CLEAR)\nstatement both within clear_inode() and iput().\n\nTo fix the bug, recheck the inode->i_count after holding i_lock.\nBecause in the most scenarios, the first check is valid, and\nthe overhead of spin_lock() can be reduced.\n\nIf there is any misunderstanding, please let me know, thanks.\n\n[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/\n[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()\nreturn false when I reproduced the bug."
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfs: arregla la ejecuci\u00f3n entre evice_inodes() y find_inode()&iput() Hola a todos Recientemente not\u00e9 un error[1] en btrfs, despu\u00e9s de investigarlo y creo que es una ejecuci\u00f3n 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\u00f3n[2] ->if (atomic_read(inode->i_count)) continue; // regresar antes // el inodo 261 pas\u00f3 la verificaci\u00f3n anterior // list_lru_add_obj() // y luego programar la salida ->spin_unlock() // nota aqu\u00ed: el inodo 261 // todav\u00eda estaba en la lista sb y la lista hash, // y I_FREEING|I_WILL_FREE no se hab\u00eda establecido btrfs_iget() // despu\u00e9s de algunas llamadas de funci\u00f3n ->find_inode() // encontr\u00f3 el inodo 261 anterior ->spin_lock(inode) // verific\u00f3 I_FREEING|I_WILL_FREE // y pas\u00f3 ->__iget() ->spin_unlock(inode) // program\u00f3 de regreso ->spin_lock(inode) // verific\u00f3 los indicadores (I_NEW|I_FREEING|I_WILL_FREE), // pas\u00f3 y estableci\u00f3 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\u00e1neamente el mismo inodo, lo que puede activar la declaraci\u00f3n 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\u00e9s de mantener i_lock. Porque en la mayor\u00eda de los escenarios, la primera verificaci\u00f3n es v\u00e1lida y se puede reducir la sobrecarga de spin_lock(). Si hay alg\u00fan malentendido, h\u00e1gamelo saber, gracias. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: La raz\u00f3n podr\u00eda ser 1. SB_ACTIVE fue eliminado o 2. mapping_shrinkable() devolvi\u00f3 falso cuando reproduje el error."
