From: Chen Ridong <chenridong@huawei.com>
To: <dhowells@redhat.com>, <jarkko@kernel.org>, <paul@paul-moore.com>,
<jmorris@namei.org>, <serge@hallyn.com>
Cc: <keyrings@vger.kernel.org>,
<linux-security-module@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <chenridong@huaweicloud.com>
Subject: [PATCH] security/keys: fix slab-out-of-bounds in key_task_permission
Date: Fri, 13 Sep 2024 07:09:28 +0000 [thread overview]
Message-ID: <20240913070928.1670785-1-chenridong@huawei.com> (raw)
We meet the same issue with the LINK, which reads memory out of bounds:
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
keyring_search_rcu+0x1b6/0x310 security/keys/keyring.c:922
search_cred_keyrings_rcu+0x111/0x2e0 security/keys/process_keys.c:459
search_process_keyrings_rcu+0x1d/0x310 security/keys/process_keys.c:544
lookup_user_key+0x782/0x12e0 security/keys/process_keys.c:762
keyctl_invalidate_key+0x20/0x190 security/keys/keyctl.c:434
__do_sys_keyctl security/keys/keyctl.c:1978 [inline]
__se_sys_keyctl+0x1de/0x5b0 security/keys/keyctl.c:1880
do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
However, we can't reproduce this issue.
After our analysis, it can make this issue by following steps.
1.As syzkaller reported, the memory is allocated for struct
assoc_array_shortcut in the assoc_array_insert_into_terminal_node
functions.
2.In the search_nested_keyrings, when we go through the slots in a node,
(bellow tag ascend_to_node), and the slot ptr is meta and
node->back_pointer != NULL, we 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.
3.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,
4.As mentioned above, If a slot of the root is a shortcut, it may be
mistakenly be transferred to a key*, leading to an read out-of-bounds
read.
To fix this issue, one should jump to descend_to_node if the pointer is a
shortcut.
Link: https://syzkaller.appspot.com/bug?id=68a5e206c2a8e08d317eb83f05610c0484ad10b9
Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
Signed-off-by: Chen Ridong <chenridong@huawei.com>
---
security/keys/keyring.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 4448758f643a..7958486ac834 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -772,7 +772,9 @@ static bool search_nested_keyrings(struct key *keyring,
for (; slot < ASSOC_ARRAY_FAN_OUT; slot++) {
ptr = READ_ONCE(node->slots[slot]);
- if (assoc_array_ptr_is_meta(ptr) && node->back_pointer)
+ if ((assoc_array_ptr_is_meta(ptr) && node->back_pointer) ||
+ (assoc_array_ptr_is_meta(ptr) &&
+ assoc_array_ptr_is_shortcut(ptr)))
goto descend_to_node;
if (!keyring_ptr_is_keyring(ptr))
--
2.34.1
next reply other threads:[~2024-09-13 7:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 7:09 Chen Ridong [this message]
2024-09-14 10:43 ` [PATCH] security/keys: fix slab-out-of-bounds in key_task_permission Chen Ridong
2024-09-14 11:33 ` Jarkko Sakkinen
2024-09-15 0:55 ` Chen Ridong
2024-09-15 13:59 ` Jarkko Sakkinen
2024-09-18 7:30 ` Chen Ridong
2024-09-18 20:57 ` Jarkko Sakkinen
2024-09-26 3:48 ` Chen Ridong
2024-09-26 8:53 ` Jarkko Sakkinen
2024-09-26 8:55 ` Jarkko Sakkinen
2024-09-26 9:54 ` Jarkko Sakkinen
2024-09-26 11:20 ` chenridong
2024-09-26 17:08 ` Jarkko Sakkinen
2024-09-27 8:20 ` chenridong
2024-10-07 23:15 ` Jarkko Sakkinen
2024-10-08 1:40 ` chenridong
2024-10-08 2:41 ` Jarkko Sakkinen
2024-10-11 2:11 ` Chen Ridong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240913070928.1670785-1-chenridong@huawei.com \
--to=chenridong@huawei.com \
--cc=chenridong@huaweicloud.com \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).