- 09 8月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1682 PR sync from: Lu Wei <luwei32@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XHWCN4LVCI4W4ZNP4NXSYHBEYGDNGBUG/ https://gitee.com/src-openeuler/kernel/issues/I7P3TK Link:https://gitee.com/openeuler/kernel/pulls/1702 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1596 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MKD6POKWLXC45KXPZXCZ7N52MPOZMNAR/ https://gitee.com/src-openeuler/kernel/issues/I7LU2Q Link:https://gitee.com/openeuler/kernel/pulls/1674 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 08 8月, 2023 4 次提交
-
-
由 Florian Westphal 提交于
stable inclusion from stable-v5.10.188 commit 3a91099ecd59a42d1632fcb152bf7222f268ea2b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7P3TK CVE: CVE-2023-4004 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3a91099ecd59a42d1632fcb152bf7222f268ea2b --------------------------- [ Upstream commit 87b5a5c209405cb6b57424cdfa226a6dbd349232 ] end key should be equal to start unless NFT_SET_EXT_KEY_END is present. Its possible to add elements that only have a start key ("{ 1.0.0.0 . 2.0.0.0 }") without an internval end. Insertion treats this via: if (nft_set_ext_exists(ext, NFT_SET_EXT_KEY_END)) end = (const u8 *)nft_set_ext_key_end(ext)->data; else end = start; but removal side always uses nft_set_ext_key_end(). This is wrong and leads to garbage remaining in the set after removal next lookup/insert attempt will give: BUG: KASAN: slab-use-after-free in pipapo_get+0x8eb/0xb90 Read of size 1 at addr ffff888100d50586 by task nft-pipapo_uaf_/1399 Call Trace: kasan_report+0x105/0x140 pipapo_get+0x8eb/0xb90 nft_pipapo_insert+0x1dc/0x1710 nf_tables_newsetelem+0x31f5/0x4e00 .. Fixes: 3c4287f6 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: Nlonial con <kongln9170@gmail.com> Reviewed-by: NStefano Brivio <sbrivio@redhat.com> Signed-off-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLu Wei <luwei32@huawei.com> (cherry picked from commit 979e0dee)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Wang ShaoBo <bobo.shaobowang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LUCQ2ZA4VCZMGUGIE3SQDRCTOPLR3TEX/ https://gitee.com/openeuler/kernel/issues/I7PN0A Link:https://gitee.com/openeuler/kernel/pulls/1656 Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1551 PR sync from: Li Nan <linan122@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ZPU6DOWXQ62ZYWCTSJSULWSJFG2MUIKX/ https://gitee.com/openeuler/kernel/issues/I7LU2I Link:https://gitee.com/openeuler/kernel/pulls/1640 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1605 PR sync from: Li Nan <linan122@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PLIYRODHJZO5O3JJ5LZMDZ5VC2QZZXUQ/ Li Nan (1): ksmbd: define SMB2_COMPRESSION_TRANSFORM_ID in fs/ksmbd/smb2pdu.h Namjae Jeon (1): ksmbd: validate smb request protocol id -- 2.39.2 https://gitee.com/openeuler/kernel/issues/I7LU2S Link:https://gitee.com/openeuler/kernel/pulls/1664 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 07 8月, 2023 4 次提交
-
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-v6.4-rc6 commit f1a41187 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7LU2Q CVE: CVE-2023-38427 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b -------------------------------- The check in the beginning is `clen + sizeof(struct smb2_neg_context) <= len_of_ctxts`, but in the end of loop, `len_of_ctxts` will subtract `((clen + 7) & ~0x7) + sizeof(struct smb2_neg_context)`, which causes integer underflow when clen does the 8 alignment. We should use `(clen + 7) & ~0x7` in the check to avoid underflow from happening. Then there are some variables that need to be declared unsigned instead of signed. [ 11.671070] BUG: KASAN: slab-out-of-bounds in smb2_handle_negotiate+0x799/0x1610 [ 11.671533] Read of size 2 at addr ffff888005e86cf2 by task kworker/0:0/7 ... [ 11.673383] Call Trace: [ 11.673541] <TASK> [ 11.673679] dump_stack_lvl+0x33/0x50 [ 11.673913] print_report+0xcc/0x620 [ 11.674671] kasan_report+0xae/0xe0 [ 11.675171] kasan_check_range+0x35/0x1b0 [ 11.675412] smb2_handle_negotiate+0x799/0x1610 [ 11.676217] ksmbd_smb_negotiate_common+0x526/0x770 [ 11.676795] handle_ksmbd_work+0x274/0x810 ... Cc: stable@vger.kernel.org Signed-off-by: NChih-Yen Chang <cc85nod@gmail.com> Tested-by: NChih-Yen Chang <cc85nod@gmail.com> Signed-off-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NSteve French <stfrench@microsoft.com> Conflict: fs/smb/server/smb2pdu.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 5df19222)
-
由 Namjae Jeon 提交于
mainline inclusion from mainline-v6.4-rc6 commit 1c1bcf2d category: bugfix bugzilla: 189016, https://gitee.com/openeuler/kernel/issues/I7LU2S CVE: CVE-2023-38430 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=1c1bcf2d3ea061613119b534f57507c377df20f9 ---------------------------------------- This patch add the validation for smb request protocol id. If it is not one of the four ids(SMB1_PROTO_NUMBER, SMB2_PROTO_NUMBER, SMB2_TRANSFORM_PROTO_NUM, SMB2_COMPRESSION_TRANSFORM_ID), don't allow processing the request. And this will fix the following KASAN warning also. [ 13.905265] BUG: KASAN: slab-out-of-bounds in init_smb2_rsp_hdr+0x1b9/0x1f0 [ 13.905900] Read of size 16 at addr ffff888005fd2f34 by task kworker/0:2/44 ... [ 13.908553] Call Trace: [ 13.908793] <TASK> [ 13.908995] dump_stack_lvl+0x33/0x50 [ 13.909369] print_report+0xcc/0x620 [ 13.910870] kasan_report+0xae/0xe0 [ 13.911519] kasan_check_range+0x35/0x1b0 [ 13.911796] init_smb2_rsp_hdr+0x1b9/0x1f0 [ 13.912492] handle_ksmbd_work+0xe5/0x820 Cc: stable@vger.kernel.org Reported-by: NChih-Yen Chang <cc85nod@gmail.com> Signed-off-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NSteve French <stfrench@microsoft.com> Conflict: fs/ksmbd/connection.c Signed-off-by: NLi Nan <linan122@huawei.com> (cherry picked from commit c8b52f21)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 189016, https://gitee.com/openeuler/kernel/issues/I7LU2S CVE: NA -------------------------------- In mainline, commit 0d35e382 ("cifs: Create a new shared file holding smb2 pdu definitions") moved 'SMB2_COMPRESSION_TRANSFORM_ID' to fs/smbfs_common/smb2pdu.h, commit 38c8a9a5 ("smb: move client and server files to common directory fs/smb") moved fs/ksmbd to fs/smb/server and included above smb2pdu.h. Now we need to use 'SMB2_COMPRESSION_TRANSFORM_ID' in fs/ksmbd. But backport all those patch is not a good iead. Just add the define in fs/ksmbd/smb2pdu.h. Signed-off-by: NLi Nan <linan122@huawei.com> (cherry picked from commit 0fbfade1)
-
由 Wang ShaoBo 提交于
hulk inclusion category: bugfix bugzilla: 189067, https://gitee.com/openeuler/kernel/issues/I7PN0A CVE: NA ------------------------------------------------- BUG 'sleeping function called from invalid context' reported when setup MPAM driver, it was blamed to bc9e3f98 ("arm64/mpam: Fix mpam corrupt when cpu online"), which reported a 'Bad PC' BUG, but missing the right conclusion, finally disabling irqs before calling cpuhp_setup_state() may only affect the probability of reproduction. The reason why triggerring 'Bad PC' BUG report is because mpam_enable() is __init type function, and may schedule out after calling __cpuhp_setup_state()->__might_sleep(), so the space of mpam_enable() might be freed after scheduling back. As we have changed mpam_enable() to non-init type function, we can revert commit bc9e3f98 directly, to solve these both two problems. Fixes: bc9e3f98 ("arm64/mpam: Fix mpam corrupt when cpu online") Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
-
- 04 8月, 2023 1 次提交
-
-
由 Chih-Yen Chang 提交于
mainline inclusion from mainline-v6.4-rc3 commit 443d61d1 category: bugfix bugzilla: 189030, https://gitee.com/openeuler/kernel/issues/I7LU2I CVE: CVE-2023-38429 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=443d61d1fa9faa60ef925513d83742902390100f ---------------------------------------- ksmbd_smb2_check_message allows client to return one byte more, so we need to allocate additional memory in ksmbd_conn_handler_loop to avoid out-of-bound access. Cc: stable@vger.kernel.org Signed-off-by: NChih-Yen Chang <cc85nod@gmail.com> Acked-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NSteve French <stfrench@microsoft.com> Conflict: fs/ksmbd/connection.c Signed-off-by: NLi Nan <linan122@huawei.com> (cherry picked from commit ff45e8b3)
-
- 03 8月, 2023 5 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1557 PR sync from: Dong Chenchen <dongchenchen2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/233WCLKDGOFGUPF6WDFRIM426TVBRFML/ https://gitee.com/src-openeuler/kernel/issues/I7N3N3 Link:https://gitee.com/openeuler/kernel/pulls/1587 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1480 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/Y2W37QUMGCXHZUAFBDA3UDH5CQW3KN2Z/ https://gitee.com/src-openeuler/kernel/issues/I7LU3D Link:https://gitee.com/openeuler/kernel/pulls/1582 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1547 PR sync from: Longlong Xia <xialonglong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MRUYLTWKNNGDLYTDA5J4NZTSS63O4NQD/ https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 Link:https://gitee.com/openeuler/kernel/pulls/1598 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1581 PR sync from: Lu Jialin <lujialin4@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PC6T7HRTE7LIGXV2HL57QYEPFKPNYTCX/ https://gitee.com/openeuler/kernel/issues/I7OOZR Link:https://gitee.com/openeuler/kernel/pulls/1601 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1591 PR sync from: Lu Wei <luwei32@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/BHZDZMZMO33GAMZUG6UGXE75EWRFJO7B/ https://gitee.com/src-openeuler/kernel/issues/I7N3N2 Link:https://gitee.com/openeuler/kernel/pulls/1614 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 02 8月, 2023 1 次提交
-
-
由 Lee Jones 提交于
stable inclusion from stable-v5.10.185 commit af6eaa57986e82d7efd81984ee607927c6de61e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3N2 CVE: CVE-2023-3609 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af6eaa57986e82d7efd81984ee607927c6de61e4 --------------------------- [ Upstream commit 04c55383 ] In the event of a failure in tcf_change_indev(), u32_set_parms() will immediately return without decrementing the recently incremented reference counter. If this happens enough times, the counter will rollover and the reference freed, leading to a double free which can be used to do 'bad things'. In order to prevent this, move the point of possible failure above the point where the reference counter is incremented. Also save any meaningful return values to be applied to the return data at the appropriate point in time. This issue was caught with KASAN. Fixes: 705c7091 ("net: sched: cls_u32: no need to call tcf_exts_change for newly allocated struct") Suggested-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NLee Jones <lee@kernel.org> Reviewed-by: NEric Dumazet <edumazet@google.com> Acked-by: NJamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLu Wei <luwei32@huawei.com> (cherry picked from commit dc7eeca1)
-
- 01 8月, 2023 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1585 PR sync from: Long Li <leo.lilong@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WWGP5YIJCFVLQK67BM5AROHE2XTHIAJ3/ https://gitee.com/src-openeuler/kernel/issues/I7LU2N Link:https://gitee.com/openeuler/kernel/pulls/1592 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Lu Jialin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OOZR ------------------------------- When CONFIG_CGROUP=n ,the compile error is: In file included from kernel/sched/core.c:13: kernel/sched/sched.h:2679:22: error: array type has incomplete element type ‘struct cftype’ extern struct cftype cgroup_v1_psi_files[]; ^~~~~~~~~~~~~~~~~~~ the reason is then CONFIG_CGROUP=n, struct cftype is not defined. We also find that, cgroup_v1_psi_files is used only in kernel/cgroup/cgroup.c and kernel/sched/cpuacct.c. Therefore, move extern struct cftype cgroup_v1_psi_files to kernel/sched/cpuacct.c.This also solved the compile error, because, then CONFIG_CGROUP=n, CONFIG_CGROUP_CPUACCT=n, the kernel/sched/cpuacct.c is not compiled, which will solve the compile error. Signed-off-by: NLu Jialin <lujialin4@huawei.com> (cherry picked from commit 61413516)
-
由 Carlos Llamas 提交于
stable inclusion from stable-v5.10.182 commit 2218752325a98861dfb10f59a9b0270d6d4abe21 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 CVE: CVE-2023-21255 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2218752325a98861dfb10f59a9b0270d6d4abe21 -------------------------------- commit bdc1c5fa upstream. In binder_transaction_buffer_release() the 'failed_at' offset indicates the number of objects to clean up. However, this function was changed by commit 44d8047f ("binder: use standard functions to allocate fds"), to release all the objects in the buffer when 'failed_at' is zero. This introduced an issue when a transaction buffer is released without any objects having been processed so far. In this case, 'failed_at' is indeed zero yet it is misinterpreted as releasing the entire buffer. This leads to use-after-free errors where nodes are incorrectly freed and subsequently accessed. Such is the case in the following KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_read+0xc40/0x1f30 Read of size 8 at addr ffff4faf037cfc58 by task poc/474 CPU: 6 PID: 474 Comm: poc Not tainted 6.3.0-12570-g7df047b3 #5 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5b8 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 binder_thread_read+0xc40/0x1f30 binder_ioctl+0xd9c/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Allocated by task 474: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xbc kmalloc_trace+0x48/0x5c binder_new_node+0x3c/0x3a4 binder_transaction+0x2b58/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] Freed by task 475: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x5c __kasan_slab_free+0xe8/0x154 __kmem_cache_free+0x128/0x2bc kfree+0x58/0x70 binder_dec_node_tmpref+0x178/0x1fc binder_transaction_buffer_release+0x430/0x628 binder_transaction+0x1954/0x36f0 binder_thread_write+0x8e0/0x1b78 binder_ioctl+0x14a0/0x1768 __arm64_sys_ioctl+0xd4/0x118 invoke_syscall+0x60/0x188 [...] ================================================================== In order to avoid these issues, let's always calculate the intended 'failed_at' offset beforehand. This is renamed and wrapped in a helper function to make it clear and convenient. Fixes: 32e9f56a ("binder: don't detect sender/target during buffer cleanup") Reported-by: NZi Fan Tan <zifantan@google.com> Cc: stable@vger.kernel.org Signed-off-by: NCarlos Llamas <cmllamas@google.com> Acked-by: NTodd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20230505203020.4101154-1-cmllamas@google.com [cmllamas: resolve trivial conflict due to missing commit 9864bb48] Signed-off-by: NCarlos Llamas <cmllamas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NWang Hai <wanghai38@huawei.com> Signed-off-by: NLonglong Xia <xialonglong1@huawei.com> (cherry picked from commit 83bfcd1e)
-
- 31 7月, 2023 5 次提交
-
-
由 Chih-Yen Chang 提交于
mainline inclusion from mainline-v6.4-rc2 commit 02f76c40 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7LU2N CVE: CVE-2023-38426 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=02f76c401d17e409ed45bf7887148fcc22c93c85 -------------------------------- Add tag_len argument in smb2_find_context_vals() to avoid out-of-bound read when create_context's name_len is larger than tag length. [ 7.995411] ================================================================== [ 7.995866] BUG: KASAN: global-out-of-bounds in memcmp+0x83/0xa0 [ 7.996248] Read of size 8 at addr ffffffff8258d940 by task kworker/0:0/7 ... [ 7.998191] Call Trace: [ 7.998358] <TASK> [ 7.998503] dump_stack_lvl+0x33/0x50 [ 7.998743] print_report+0xcc/0x620 [ 7.999458] kasan_report+0xae/0xe0 [ 7.999895] kasan_check_range+0x35/0x1b0 [ 8.000152] memcmp+0x83/0xa0 [ 8.000347] smb2_find_context_vals+0xf7/0x1e0 [ 8.000635] smb2_open+0x1df2/0x43a0 [ 8.006398] handle_ksmbd_work+0x274/0x810 [ 8.006666] process_one_work+0x419/0x760 [ 8.006922] worker_thread+0x2a2/0x6f0 [ 8.007429] kthread+0x160/0x190 [ 8.007946] ret_from_fork+0x1f/0x30 [ 8.008181] </TASK> Cc: stable@vger.kernel.org Signed-off-by: NChih-Yen Chang <cc85nod@gmail.com> Acked-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NLong Li <leo.lilong@huawei.com> (cherry picked from commit 1997409a)
-
由 M A Ramdhan 提交于
stable inclusion from stable-v5.10.187 commit 80e0e8d5f54397c5048fa2274144134dd9dc91b5 category: bugfix bugzilla: 189032,https://gitee.com/src-openeuler/kernel/issues/I7N3N3 CVE: CVE-2023-3776 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=80e0e8d5f54397c5048fa2274144134dd9dc91b5 --------------------------- [ Upstream commit 0323bce598eea038714f941ce2b22541c46d488f ] In the event of a failure in tcf_change_indev(), fw_set_parms() will immediately return an error after incrementing or decrementing reference counter in tcf_bind_filter(). If attacker can control reference counter to zero and make reference freed, leading to use after free. In order to prevent this, move the point of possible failure above the point where the TC_FW_CLASSID is handled. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: NM A Ramdhan <ramdhan@starlabs.sg> Signed-off-by: NM A Ramdhan <ramdhan@starlabs.sg> Acked-by: NJamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: NPedro Tammela <pctammela@mojatatu.com> Message-ID: <20230705161530.52003-1-ramdhan@starlabs.sg> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com> (cherry picked from commit 85657d6d)
-
由 Chih-Yen Chang 提交于
mainline inclusion from mainline-v6.4-rc3 commit f0a96d1a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7LU3D CVE: CVE-2023-38428 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f -------------------------------- The offset of UserName is related to the address of security buffer. To ensure the validaty of UserName, we need to compare name_off + name_len with secbuf_len instead of auth_msg_len. [ 27.096243] ================================================================== [ 27.096890] BUG: KASAN: slab-out-of-bounds in smb_strndup_from_utf16+0x188/0x350 [ 27.097609] Read of size 2 at addr ffff888005e3b542 by task kworker/0:0/7 ... [ 27.099950] Call Trace: [ 27.100194] <TASK> [ 27.100397] dump_stack_lvl+0x33/0x50 [ 27.100752] print_report+0xcc/0x620 [ 27.102305] kasan_report+0xae/0xe0 [ 27.103072] kasan_check_range+0x35/0x1b0 [ 27.103757] smb_strndup_from_utf16+0x188/0x350 [ 27.105474] smb2_sess_setup+0xaf8/0x19c0 [ 27.107935] handle_ksmbd_work+0x274/0x810 [ 27.108315] process_one_work+0x419/0x760 [ 27.108689] worker_thread+0x2a2/0x6f0 [ 27.109385] kthread+0x160/0x190 [ 27.110129] ret_from_fork+0x1f/0x30 [ 27.110454] </TASK> Cc: stable@vger.kernel.org Signed-off-by: NChih-Yen Chang <cc85nod@gmail.com> Acked-by: NNamjae Jeon <linkinjeon@kernel.org> Signed-off-by: NSteve French <stfrench@microsoft.com> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 2a2a280a)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhong Jinghua <zhongjinghua@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LJ33GFFSQF355SJLQXOUOLZRUVMBCUJ5/ Fix null-ptr-deref while calling getpeername Mike Christie (1): scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Zhong Jinghua (1): scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param() -- 2.31.1 https://gitee.com/openeuler/kernel/issues/I7L8DZ?from=project-issue https://gitee.com/openeuler/kernel/issues/I6I8YD Link:https://gitee.com/openeuler/kernel/pulls/1467 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1535 PR sync from: Zhengchao Shao <shaozhengchao@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/75DAZGK4S4I77M34YBBAMEVTKPX2NSLQ/ https://gitee.com/src-openeuler/kernel/issues/I7N3MX Link:https://gitee.com/openeuler/kernel/pulls/1573 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 29 7月, 2023 6 次提交
-
-
由 Pedro Tammela 提交于
mainline inclusion from mainline-v6.5-rc2 commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3MX CVE: CVE-2023-3611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64 --------------------------- Lion says: ------- In the QFQ scheduler a similar issue to CVE-2023-31436 persists. Consider the following code in net/sched/sch_qfq.c: static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free) { unsigned int len = qdisc_pkt_len(skb), gso_segs; // ... if (unlikely(cl->agg->lmax < len)) { pr_debug("qfq: increasing maxpkt from %u to %u for class %u", cl->agg->lmax, len, cl->common.classid); err = qfq_change_agg(sch, cl, cl->agg->class_weight, len); if (err) { cl->qstats.drops++; return qdisc_drop(skb, sch, to_free); } // ... } Similarly to CVE-2023-31436, "lmax" is increased without any bounds checks according to the packet length "len". Usually this would not impose a problem because packet sizes are naturally limited. This is however not the actual packet length, rather the "qdisc_pkt_len(skb)" which might apply size transformations according to "struct qdisc_size_table" as created by "qdisc_get_stab()" in net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc. A user may choose virtually any size using such a table. As a result the same issue as in CVE-2023-31436 can occur, allowing heap out-of-bounds read / writes in the kmalloc-8192 cache. ------- We can create the issue with the following commands: tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \ overhead 999999999 linklayer ethernet qfq tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k tc filter add dev $DEV parent 1: matchall classid 1:1 ping -I $DEV 1.1.1.2 This is caused by incorrectly assuming that qdisc_pkt_len() returns a length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX. Fixes: 462dbc91 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: NLion <nnamrec@gmail.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NPedro Tammela <pctammela@mojatatu.com> Reviewed-by: NSimon Horman <simon.horman@corigine.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Conflicts: net/sched/sch_qfq.c Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> (cherry picked from commit 6d004dad)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1548 PR sync from: Lu Jialin <lujialin4@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/IEFAD56CINP4C7F25QETI2JXGD3QOHWH/ https://gitee.com/openeuler/kernel/issues/I7NXZ6?from=project-issue Link:https://gitee.com/openeuler/kernel/pulls/1558 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1351 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7LQ6EXG6AUW5V5QHM5OPQF4H2EUFST7H/ Link:https://gitee.com/openeuler/kernel/pulls/1380 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1294 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JMXBT7PXZENQ6R7L2JBRQLXB3NS26AY2/ Link:https://gitee.com/openeuler/kernel/pulls/1349 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/3GH4GOG4AWQWHSAMBTS4ZV7OXVQKBRUE/ https://gitee.com/openeuler/kernel/issues/I7F7J3 Link:https://gitee.com/openeuler/kernel/pulls/1502 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1345 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2PV7QOUKZR3DCG46HYA5N3UC6X6ZZ3EU/ It's not proper to just abort IO when the map is not ready. So revert this and requeue IO to keep consistent with the community. And fix the deadlock introduced by the patch. v1->v2: add patch 38d11da5 "dm: don't lock fs when the map is NULL in process of resume" Li Lingfeng (3): Revert "dm: make sure dm_table is binded before queue request" dm: don't lock fs when the map is NULL in process of resume dm: don't lock fs when the map is NULL during suspend or resume Mike Snitzer (1): dm: requeue IO if mapping table not yet available -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/1477 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 28 7月, 2023 1 次提交
-
-
由 Muchun Song 提交于
mainline inclusion from mainline-v5.18-rc1 commit be740503 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NXZ6?from=project-issue Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be740503ed03ea04ca362330baf082e6a38fe462 -------------------------------- The idr_alloc() does not include @max ID. So in the current implementation, the maximum memcg ID is 65534 instead of 65535. It seems a bug. So fix this. Link: https://lkml.kernel.org/r/20220228122126.37293-15-songmuchun@bytedance.comSigned-off-by: NMuchun Song <songmuchun@bytedance.com> Cc: Alex Shi <alexs@kernel.org> Cc: Anna Schumaker <Anna.Schumaker@Netapp.com> Cc: Chao Yu <chao@kernel.org> Cc: Dave Chinner <david@fromorbit.com> Cc: Fam Zheng <fam.zheng@bytedance.com> Cc: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kari Argillander <kari.argillander@gmail.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Qi Zheng <zhengqi.arch@bytedance.com> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeelb@google.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: Xiongchun Duan <duanxiongchun@bytedance.com> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Conflict: mm/memcontrol.c Signed-off-by: NLu Jialin <lujialin4@huawei.com> (cherry picked from commit 763ab5c7)
-
- 25 7月, 2023 5 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1482 PR sync from: Lu Jialin <lujialin4@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MIDF5L7L2X2TOVLMC5V5F4QF7ZAKGN5I/ First is the patch to fix CVE-2023-3567. The latter two patches are the bugfix patches for the first patch. George Kennedy (2): vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF vc_screen: modify vcs_size() handling in vcs_read() Thomas Weißschuh (1): vc_screen: don't clobber return value in vcs_read -- 2.17.1 https://gitee.com/src-openeuler/kernel/issues/I7JRBO?from=project-issue Link:https://gitee.com/openeuler/kernel/pulls/1524 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1335 PR sync from: Pu Lehui <pulehui@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/U3JJGUSJTF5PH22SUDWUTPBSGUN6AUFJ/ Link:https://gitee.com/openeuler/kernel/pulls/1337 Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 George Kennedy 提交于
stable inclusion from stable-v5.10.173 commit 3e734e694181b27687ce17da3229aa8edfd21760 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7JRBO?from=project-issue Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3e734e694181b27687ce17da3229aa8edfd21760 -------------------------------- [ Upstream commit 46d733d0 ] Restore the vcs_size() handling in vcs_read() to what it had been in previous version. Fixes: 226fae12 ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") Suggested-by: NJiri Slaby <jirislaby@kernel.org> Signed-off-by: NGeorge Kennedy <george.kennedy@oracle.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLu Jialin <lujialin4@huawei.com> (cherry picked from commit 60927aaa)
-
由 Thomas Weißschuh 提交于
stable inclusion from stable-v5.10.171 commit 80653a6e6e287eb982be9aa9f60f94382b6767b5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7JRBO?from=project-issue Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=80653a6e6e287eb982be9aa9f60f94382b6767b5 -------------------------------- commit ae3419fb upstream. Commit 226fae12 ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop. While doing this it also moved the unconditional assignment of ret = -ENXIO; This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret. To avoid this only assign "ret = -ENXIO" when actually needed. [ Also, the 'goto unlock_out" needs to be just a "break", so that it does the right thing when it exits on later iterations when partial success has happened - Linus ] Reported-by: NStorm Dragon <stormdragon2976@gmail.com> Link: https://lore.kernel.org/lkml/Y%2FKS6vdql2pIsCiI@hotmail.com/ Fixes: 226fae12 ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") Signed-off-by: NThomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/lkml/64981d94-d00c-4b31-9063-43ad0a384bde@t-8ch.de/Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLu Jialin <lujialin4@huawei.com> (cherry picked from commit bbfa62b2)
-
由 George Kennedy 提交于
stable inclusion from stable-v5.10.168 commit 55515d7d8743b71b80bfe68e89eb9d92630626ab category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7JRBO?from=project-issue Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=55515d7d8743b71b80bfe68e89eb9d92630626ab -------------------------------- [ Upstream commit 226fae12 ] After a call to console_unlock() in vcs_read() the vc_data struct can be freed by vc_deallocate(). Because of that, the struct vc_data pointer load must be done at the top of while loop in vcs_read() to avoid a UAF when vcs_size() is called. Syzkaller reported a UAF in vcs_size(). BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215) Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537 CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module Call Trace: <TASK> __asan_report_load4_noabort (mm/kasan/report_generic.c:350) vcs_size (drivers/tty/vt/vc_screen.c:215) vcs_read (drivers/tty/vt/vc_screen.c:415) vfs_read (fs/read_write.c:468 fs/read_write.c:450) ... </TASK> Allocated by task 1191: ... kmalloc_trace (mm/slab_common.c:1069) vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720 drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108) con_install (drivers/tty/vt/vt.c:3383) tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413 drivers/tty/tty_io.c:1390) tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126) chrdev_open (fs/char_dev.c:415) do_dentry_open (fs/open.c:883) vfs_open (fs/open.c:1014) ... Freed by task 1548: ... kfree (mm/slab_common.c:1021) vc_port_destruct (drivers/tty/vt/vt.c:1094) tty_port_destructor (drivers/tty/tty_port.c:296) tty_port_put (drivers/tty/tty_port.c:312) vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2)) vt_ioctl (drivers/tty/vt/vt_ioctl.c:903) tty_ioctl (drivers/tty/tty_io.c:2776) ... The buggy address belongs to the object at ffff888113747800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 424 bytes inside of 1024-byte region [ffff888113747800, ffff888113747c00) The buggy address belongs to the physical page: page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x113740 head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0 anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint Fixes: ac751efa ("console: rename acquire/release_console_sem() to console_lock/unlock()") Reported-by: Nsyzkaller <syzkaller@googlegroups.com> Suggested-by: NJiri Slaby <jirislaby@kernel.org> Signed-off-by: NGeorge Kennedy <george.kennedy@oracle.com> Link: https://lore.kernel.org/r/1674577014-12374-1-git-send-email-george.kennedy@oracle.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLu Jialin <lujialin4@huawei.com> (cherry picked from commit cb200978)
-
- 24 7月, 2023 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhang Zekun <zhangzekun11@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HUXQSPZIXCAFEIF76HH4ELUNOET33ILO/ Fix problem introduced by feature CDM node, which might alloc memory from other no cdm nodes. Zhou Guanghui (2): mm: fix ignore cpuset enforcement mm: fix alloc CDM node memory for MPOL_BIND -- 2.17.1 https://gitee.com/openeuler/kernel/issues/I612UG Link:https://gitee.com/openeuler/kernel/pulls/1515 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Weilong Chen <chenweilong@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I612UG CVE: NA ------------------------------------------------------ Memory can be allocated from a specified CDM node only when it is allowed to apply for memory from the CDM node. Otherwise, memory will be allocated from other non-CDM nodes that are not allowed by th cpuset. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I612UG CVE: NA ----------------------------------------------------- Since the current condition ignores the cpuset enforcement by adding __GFP_THISNODEi to the gfp_mask, this will result in allocations that specify __GFP_THISNODE and non-cdm nodes not subject to cpuset restrictions. For example, procA pid 1000: node 0 cpus: 0 1 2 3 node 0 free: 57199MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB cpuset/test/cpuset.mems 1 cpuset/test/tasks 1000 cpuset/test/cpuset.cpus 0-3 No cdm node exists. When procA malloc 100MB memory, the result is: node 0 cpus: 0 1 2 3 node 0 free: 57099MB node 1 cpus: 4 5 6 7 node 1 free: 55930MB This is not what we expected, and in fact 100 MB of memory should be allocated from node1. The reason for this problem is that THP specifies __GFP_THISNODE to attempt to allocate from the local node. Therefore, the cpuset enforcement should be ignored only when explicitly allocating memory from the cdm node using __GFP_ THISNODE. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
-