ghsa-7h56-8w9m-w78x
Vulnerability from github
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 | +---+
- 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.]
{
"affected": [],
"aliases": [
"CVE-2024-50301"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:32Z",
"severity": "HIGH"
},
"details": "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 \u00270xxxxxxxe6\u0027.\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-\u003eback_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 +------\u003e+---+\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.]",
"id": "GHSA-7h56-8w9m-w78x",
"modified": "2024-11-21T21:33:31Z",
"published": "2024-11-19T03:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a74da044ec9ec8679e6beccc4306b936b62873f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e4fdec8b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.