CVE-2024-50301

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> security/keys: fix slab-out-of-bounds in key_task_permission<br /> <br /> KASAN reports an out of bounds read:<br /> BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36<br /> BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]<br /> BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410<br /> security/keys/permission.c:54<br /> Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362<br /> <br /> CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:82 [inline]<br /> dump_stack+0x107/0x167 lib/dump_stack.c:123<br /> print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400<br /> __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560<br /> kasan_report+0x3a/0x50 mm/kasan/report.c:585<br /> __kuid_val include/linux/uidgid.h:36 [inline]<br /> uid_eq include/linux/uidgid.h:63 [inline]<br /> key_task_permission+0x394/0x410 security/keys/permission.c:54<br /> search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793<br /> <br /> This issue was also reported by syzbot.<br /> <br /> It can be reproduced by following these steps(more details [1]):<br /> 1. Obtain more than 32 inputs that have similar hashes, which ends with the<br /> pattern &amp;#39;0xxxxxxxe6&amp;#39;.<br /> 2. Reboot and add the keys obtained in step 1.<br /> <br /> The reproducer demonstrates how this issue happened:<br /> 1. In the search_nested_keyrings function, when it iterates through the<br /> slots in a node(below tag ascend_to_node), if the slot pointer is meta<br /> and node-&gt;back_pointer != NULL(it means a root), it will proceed to<br /> descend_to_node. However, there is an exception. If node is the root,<br /> and one of the slots points to a shortcut, it will be treated as a<br /> keyring.<br /> 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.<br /> However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as<br /> ASSOC_ARRAY_PTR_SUBTYPE_MASK.<br /> 3. When 32 keys with the similar hashes are added to the tree, the ROOT<br /> has keys with hashes that are not similar (e.g. slot 0) and it splits<br /> NODE A without using a shortcut. When NODE A is filled with keys that<br /> all hashes are xxe6, the keys are similar, NODE A will split with a<br /> shortcut. Finally, it forms the tree as shown below, where slot 6 points<br /> to a shortcut.<br /> <br /> NODE A<br /> +------&gt;+---+<br /> ROOT | | 0 | xxe6<br /> +---+ | +---+<br /> xxxx | 0 | shortcut : : xxe6<br /> +---+ | +---+<br /> xxe6 : : | | | xxe6<br /> +---+ | +---+<br /> | 6 |---+ : : xxe6<br /> +---+ +---+<br /> xxe6 : : | f | xxe6<br /> +---+ +---+<br /> xxe6 | f |<br /> +---+<br /> <br /> 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,<br /> it may be mistakenly transferred to a key*, leading to a read<br /> out-of-bounds read.<br /> <br /> To fix this issue, one should jump to descend_to_node if the ptr is a<br /> shortcut, regardless of whether the node is root or not.<br /> <br /> [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/<br /> <br /> [jarkko: tweaked the commit message a bit to have an appropriate closes<br /> tag.]