- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] security/keys: fix slab-out-of-bounds in key_task_permission
by Yi Yang 16 Oct '24

16 Oct '24

From: Chen Ridong <chenridong(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 -------------------------------- The following bug was triggered when performing syzkaller test: 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 This issue was also reported by syzbot [1]. It can be reproduced by following these steps(more details [2]): 1.Obtain more than 32 inputs that have similar hashes, which end 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), and the slot pointer is meta and node->back_pointer != NULL, 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 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. [1] https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ [2] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@h… Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3(a)syzkaller.appspotmail.com Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)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 e8f2366021ea..8a6d891be55e 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -739,7 +739,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_shortcut(ptr))) goto descend_to_node; if (!keyring_ptr_is_keyring(ptr)) -- 2.25.1

2 1

[PTACH openEuler-1.0-LTS] security/keys: fix slab-out-of-bounds in key_task_permission
by Yi Yang 16 Oct '24

16 Oct '24

From: Chen Ridong <chenridong(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 -------------------------------- The following bug was triggered when performing syzkaller test: 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 This issue was also reported by syzbot [1]. It can be reproduced by following these steps(more details [2]): 1.Obtain more than 32 inputs that have similar hashes, which end 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), and the slot pointer is meta and node->back_pointer != NULL, 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 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. [1] https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ [2] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@h… Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3(a)syzkaller.appspotmail.com Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)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 e8f2366021ea..8a6d891be55e 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -739,7 +739,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_shortcut(ptr))) goto descend_to_node; if (!keyring_ptr_is_keyring(ptr)) -- 2.25.1

1 0

[PATCH OLK-5.10 0/2] nbd: Fix signal handling
by Yu Kuai 16 Oct '24

16 Oct '24

Bart Van Assche (2): nbd: Improve the documentation of the locking assumptions nbd: Fix signal handling drivers/block/nbd.c | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6] security/keys: fix slab-out-of-bounds in key_task_permission
by Yi Yang 16 Oct '24

16 Oct '24

From: Chen Ridong <chenridong(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 -------------------------------- The following bug was triggered when performing syzkaller test: 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 This issue was also reported by syzbot [1]. It can be reproduced by following these steps(more details [2]): 1.Obtain more than 32 inputs that have similar hashes, which end 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), and the slot pointer is meta and node->back_pointer != NULL, 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 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. [1] https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ [2] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@h… Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3(a)syzkaller.appspotmail.com Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)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..747ae047ae1c 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_shortcut(ptr))) goto descend_to_node; if (!keyring_ptr_is_keyring(ptr)) -- 2.25.1

2 1

[PATCH OLK-5.10] security/keys: fix slab-out-of-bounds in key_task_permission
by Yi Yang 16 Oct '24

16 Oct '24

From: Chen Ridong <chenridong(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 -------------------------------- The following bug was triggered when performing syzkaller test: 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 This issue was also reported by syzbot [1]. It can be reproduced by following these steps(more details [2]): 1.Obtain more than 32 inputs that have similar hashes, which end 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), and the slot pointer is meta and node->back_pointer != NULL, 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 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. [1] https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ [2] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@h… Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3(a)syzkaller.appspotmail.com Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)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 14abfe765b7e..700409d815a9 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_shortcut(ptr))) goto descend_to_node; if (!keyring_ptr_is_keyring(ptr)) -- 2.25.1

2 1

[PTACH openEuler-1.0-LTS] security/keys: fix slab-out-of-bounds in key_task_permission
by Yi Yang 16 Oct '24

16 Oct '24

From: Chen Ridong <chenridong(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAU173 -------------------------------- The following bug was triggered when performing syzkaller test: 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 This issue was also reported by syzbot [1]. It can be reproduced by following these steps(more details [2]): 1.Obtain more than 32 inputs that have similar hashes, which end 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), and the slot pointer is meta and node->back_pointer != NULL, 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 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. [1] https://lore.kernel.org/all/000000000000cbb7860611f61147@google.com/T/ [2] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@h… Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring") Reported-by: syzbot+5b415c07907a2990d1a3(a)syzkaller.appspotmail.com Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Yi Yang <yiyang13(a)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 e8f2366021ea..8a6d891be55e 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -739,7 +739,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_shortcut(ptr))) goto descend_to_node; if (!keyring_ptr_is_keyring(ptr)) -- 2.25.1

1 0

[openeuler:OLK-6.6] BUILD REGRESSION 30113d2856fb1359049f1be9aba9bd59a5c4dcf0
by kernel test robot 16 Oct '24

16 Oct '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 30113d2856fb1359049f1be9aba9bd59a5c4dcf0 !12112 [openEuler-24.03-LTS][linux-6.6.y sync] Backport 6.6.47-6.6.48 LTS Patches Error/Warning (recently discovered and may have been fixed): net/ipv4/tcp_comp.c:740:6: warning: no previous prototype for 'comp_stream_read' [-Wmissing-prototypes] net/ipv4/tcp_comp.c:779:6: warning: no previous prototype for 'comp_setup_strp' [-Wmissing-prototypes] Error/Warning ids grouped by kconfigs: recent_errors |-- loongarch-allnoconfig | |-- arch-loongarch-kernel-efi.c:error:incompatible-types-when-assigning-to-type-pmd_t-from-type-int | `-- drivers-irqchip-irq-loongson-eiointc.c:error:NODES_PER_FLATMODE_NODE-undeclared-(first-use-in-this-function) |-- loongarch-allyesconfig | |-- net-ipv4-tcp_comp.c:warning:no-previous-prototype-for-comp_setup_strp | `-- net-ipv4-tcp_comp.c:warning:no-previous-prototype-for-comp_stream_read |-- x86_64-rhel-8.3 | |-- drivers-crypto-ccp-hygon-csv-dev.c:warning:no-previous-prototype-for-vpsp_do_cmd | |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-Directly-convert-the-gpa-address-into-hpa-and-forward-it-to-PSP | |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-copy-data-in-gpa-to-host-memory-and-send-it-to-psp-for-processing. | `-- drivers-crypto-ccp-hygon-vpsp.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst |-- x86_64-rhel-8.3-func | |-- drivers-crypto-ccp-hygon-csv-dev.c:warning:no-previous-prototype-for-vpsp_do_cmd | |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-Directly-convert-the-gpa-address-into-hpa-and-forward-it-to-PSP | |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-copy-data-in-gpa-to-host-memory-and-send-it-to-psp-for-processing. | `-- drivers-crypto-ccp-hygon-vpsp.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst `-- x86_64-rhel-8.3-kselftests |-- drivers-crypto-ccp-hygon-csv-dev.c:warning:no-previous-prototype-for-vpsp_do_cmd |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-Directly-convert-the-gpa-address-into-hpa-and-forward-it-to-PSP |-- drivers-crypto-ccp-hygon-vpsp.c:warning:Cannot-understand-brief-copy-data-in-gpa-to-host-memory-and-send-it-to-psp-for-processing. `-- drivers-crypto-ccp-hygon-vpsp.c:warning:This-comment-starts-with-but-isn-t-a-kernel-doc-comment.-Refer-Documentation-doc-guide-kernel-doc.rst elapsed time: 2211m configs tested: 7 configs skipped: 39 tested configs: arm64 allnoconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 defconfig gcc-11 x86_64 kexec clang-18 x86_64 rhel-8.3 gcc-12 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-46826
by Gu Bowen 15 Oct '24

15 Oct '24

Fix CVE-2024-46826 Alexey Dobriyan (1): ELF: fix kernel.randomize_va_space double read Gu Bowen (1): ELF: Fix mixed declarations and code of "snapshot_randomize_va_space" fs/binfmt_elf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10 v7 00/12] xfs: some fix for forcealign
by Long Li 15 Oct '24

15 Oct '24

This patch set fix some bug for forcealign: patch 1 ~ 5 : fix tail alignment issue while approach to no space. patch 6 : fix forcealign not compatible with reflink and realtime. patch 7 : only datafork need bunmap algin for focealign patch 8 ~ 11 : fix truncate for forcealign Dave Chinner (3): xfs: only allow minlen allocations when near ENOSPC xfs: always tail align maxlen allocations xfs: align args->minlen for forced allocation alignment John Garry (1): xfs: Don't revert allocated offset for forcealign Long Li (5): xfs: don't attempting non-aligned fallbacks alloc for forcealign xfs: simplify extent allocation alignment xfs: forcealign not compatible with reflink and realtime device xfs: only bunmap align in datafork for forcealign xfs: correct the truncate blocksize of forcealign Zhang Yi (3): math64: add rem_u64() to just return the remainder iomap: pass blocksize to iomap_truncate_page() xfs: refactor the truncating order fs/iomap/buffered-io.c | 8 +-- fs/xfs/libxfs/xfs_alloc.c | 31 +++++---- fs/xfs/libxfs/xfs_bmap.c | 140 ++++++++++++++++++++------------------ fs/xfs/xfs_iops.c | 124 +++++++++++++++++---------------- fs/xfs/xfs_super.c | 19 +++++- include/linux/iomap.h | 4 +- include/linux/math64.h | 24 +++++++ 7 files changed, 208 insertions(+), 142 deletions(-) -- 2.39.2

2 13

[PATCH OLK-6.6] [Backport] KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS
by Zhao Yipeng 15 Oct '24

15 Oct '24

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.6.51 commit 939375737b5a0b1bf9b1e75129054e11bc9ca65e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9K5 CVE: CVE-2024-46830 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS commit 4bcdd831d9d01e0fb64faea50732b59b2ee88da1 upstream. Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory. Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm] stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK> Fixes: f7e570780efc ("KVM: x86: Forcibly leave nested virt when SMM state is toggled") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240723232055.3643811-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhao Yipeng <zhaoyipeng5(a)huawei.com> --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 5e62759bbbc4..21c624170f31 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5915,7 +5915,9 @@ long kvm_arch_vcpu_ioctl(struct file *filp, if (copy_from_user(&events, argp, sizeof(struct kvm_vcpu_events))) break; + kvm_vcpu_srcu_read_lock(vcpu); r = kvm_vcpu_ioctl_x86_set_vcpu_events(vcpu, &events); + kvm_vcpu_srcu_read_unlock(vcpu); break; } case KVM_GET_DEBUGREGS: { -- 2.34.1

2 1

2025

2024

2023

2022

2021

2020

2019

Kernel