"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsecurity/keys: fix slab-out-of-bounds in key_task_permission\n\nKASAN reports an out of bounds read:\nBUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36\nBUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]\nBUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410\nsecurity/keys/permission.c:54\nRead of size 4 at addr ffff88813c3ab618 by task stress-ng/4362\n\nCPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15\nCall Trace:\n __dump_stack lib/dump_stack.c:82 [inline]\n dump_stack+0x107/0x167 lib/dump_stack.c:123\n print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400\n __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560\n kasan_report+0x3a/0x50 mm/kasan/report.c:585\n __kuid_val include/linux/uidgid.h:36 [inline]\n uid_eq include/linux/uidgid.h:63 [inline]\n key_task_permission+0x394/0x410 security/keys/permission.c:54\n search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793\n\nThis issue was also reported by syzbot.\n\nIt can be reproduced by following these steps(more details [1]):\n1. Obtain more than 32 inputs that have similar hashes, which ends with the\n pattern '0xxxxxxxe6'.\n2. Reboot and add the keys obtained in step 1.\n\nThe reproducer demonstrates how this issue happened:\n1. In the search_nested_keyrings function, when it iterates through the\n slots in a node(below tag ascend_to_node), if the slot pointer is meta\n and node->back_pointer != NULL(it means a root), it will proceed to\n descend_to_node. However, there is an exception. If node is the root,\n and one of the slots points to a shortcut, it will be treated as a\n keyring.\n2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.\n However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as\n ASSOC_ARRAY_PTR_SUBTYPE_MASK.\n3. When 32 keys with the similar hashes are added to the tree, the ROOT\n has keys with hashes that are not similar (e.g. slot 0) and it splits\n NODE A without using a shortcut. When NODE A is filled with keys that\n all hashes are xxe6, the keys are similar, NODE A will split with a\n shortcut. Finally, it forms the tree as shown below, where slot 6 points\n to a shortcut.\n\n NODE A\n +------>+---+\n ROOT | | 0 | xxe6\n +---+ | +---+\n xxxx | 0 | shortcut : : xxe6\n +---+ | +---+\n xxe6 : : | | | xxe6\n +---+ | +---+\n | 6 |---+ : : xxe6\n +---+ +---+\n xxe6 : : | f | xxe6\n +---+ +---+\n xxe6 | f |\n +---+\n\n4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,\n it may be mistakenly transferred to a key*, leading to a read\n out-of-bounds read.\n\nTo fix this issue, one should jump to descend_to_node if the ptr is a\nshortcut, regardless of whether the node is root or not.\n\n[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/\n\n[jarkko: tweaked the commit message a bit to have an appropriate closes\n tag.]"
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: security/keys: correcci\u00f3n de slab-out-of-bounds en key_task_permission KASAN informa una lectura fuera de los l\u00edmites: ERROR: KASAN: slab-out-of-bounds en __kuid_val include/linux/uidgid.h:36 ERROR: KASAN: slab-out-of-bounds en uid_eq include/linux/uidgid.h:63 [en l\u00ednea] ERROR: KASAN: slab-out-of-bounds en key_task_permission+0x394/0x410 security/keys/permission.c:54 Lectura de tama\u00f1o 4 en la direcci\u00f3n ffff88813c3ab618 por la tarea stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng No contaminado 5.10.0-14930-gafbffd6c3ede #15 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:82 [en l\u00ednea] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [en l\u00ednea] uid_eq include/linux/uidgid.h:63 [en l\u00ednea] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 Este problema tambi\u00e9n fue informado por syzbot. Puede reproducirse siguiendo estos pasos (m\u00e1s detalles [1]): 1. Obtenga m\u00e1s de 32 entradas que tengan hashes similares, que terminen con el patr\u00f3n '0xxxxxxxe6'. 2. Reinicie y agregue las claves obtenidas en el paso 1. El reproductor demuestra c\u00f3mo sucedi\u00f3 este problema: 1. En la funci\u00f3n search_nested_keyrings, cuando itera a trav\u00e9s de las ranuras en un nodo (debajo de la etiqueta ascend_to_node), si el puntero de la ranura es meta y node->back_pointer != NULL (significa una ra\u00edz), proceder\u00e1 a descend_to_node. Sin embargo, hay una excepci\u00f3n. Si el nodo es la ra\u00edz y una de las ranuras apunta a un acceso directo, se tratar\u00e1 como un llavero. 2. Si el ptr es un llavero lo decide la funci\u00f3n keyring_ptr_is_keyring. Sin embargo, KEYRING_PTR_SUBTYPE es 0x2UL, lo mismo que ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. Cuando se agregan 32 claves con hashes similares al \u00e1rbol, la RA\u00cdZ tiene claves con hashes que no son similares (por ejemplo, la ranura 0) y divide el NODO A sin usar un acceso directo. Cuando el NODO A se llena con claves en las que todos los hashes son xxe6, las claves son similares, el NODO A se dividir\u00e1 con un acceso directo. Finalmente, forma el \u00e1rbol como se muestra a continuaci\u00f3n, donde la ranura 6 apunta a un acceso directo. NODO A +------>+---+ RA\u00cdZ | | 0 | xxe6 +---+ | +---+ xxxx | 0 | acceso directo : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. Como se mencion\u00f3 anteriormente, si una ranura (ranura 6) de la ra\u00edz apunta a un acceso directo, puede transferirse por error a una clave*, lo que lleva a una lectura fuera de los l\u00edmites. Para solucionar este problema, uno debe saltar a descend_to_node si el ptr es un acceso directo, independientemente de si el nodo es ra\u00edz o no. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: modifiqu\u00e9 un poco el mensaje de confirmaci\u00f3n para tener una etiqueta de cierre apropiada]."
