Message-ID: <2024111907-CVE-2024-50301-ec76@gregkh>
Date: Tue, 19 Nov 2024 02:32:56 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2024-50301: security/keys: fix slab-out-of-bounds in key_task_permission

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

security/keys: fix slab-out-of-bounds in key_task_permission

KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 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 [inline]
 uid_eq include/linux/uidgid.h:63 [inline]
 key_task_permission+0x394/0x410 security/keys/permission.c:54
 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
   pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
   slots in a node(below tag ascend_to_node), if the slot pointer is meta
   and node->back_pointer != NULL(it means a root), it will proceed to
   descend_to_node. However, there is an exception. If node is the root,
   and one of the slots points to a shortcut, it will be treated as a
   keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
   ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
   has keys with hashes that are not similar (e.g. slot 0) and it splits
   NODE A without using a shortcut. When NODE A is filled with keys that
   all hashes are xxe6, the keys are similar, NODE A will split with a
   shortcut. Finally, it forms the tree as shown below, where slot 6 points
   to a shortcut.

                      NODE A
              +------>+---+
      ROOT    |       | 0 | xxe6
      +---+   |       +---+
 xxxx | 0 | shortcut  :   : xxe6
      +---+   |       +---+
 xxe6 :   :   |       |   | xxe6
      +---+   |       +---+
      | 6 |---+       :   : xxe6
      +---+           +---+
 xxe6 :   :           | f | xxe6
      +---+           +---+
 xxe6 | f |
      +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
   it may be mistakenly transferred to a key*, leading to a read
   out-of-bounds read.

To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes
 tag.]

The Linux kernel CVE team has assigned CVE-2024-50301 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 4.19.324 with commit c3ce634ad953
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 5.4.286 with commit 4efb69a0e294
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 5.10.230 with commit 1e4332581cd4
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 5.15.172 with commit 199c20fb7499
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 6.1.117 with commit bbad2d5b6c99
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 6.6.61 with commit 3e79ad156bed
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 6.11.8 with commit e0a317ad68e4
	Issue introduced in 3.13 with commit b2a4df200d57 and fixed in 6.12 with commit 4a74da044ec9

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-50301
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	security/keys/keyring.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f
	https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d
	https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9
	https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce
	https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881
	https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79
	https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e4fdec8b
	https://git.kernel.org/stable/c/4a74da044ec9ec8679e6beccc4306b936b62873f

Powered by blists - more mailing lists