- 09 8月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @did-you-collect-the-wool-today virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7QPGW CVE: NA ------------------------------------------------------------------ In probe_vendor_drivers, all registered vendor drivers are traversed. This is not a good idea. If a vendor driver is not implemented well enough, it may cause the system to panic. Use the vendor id and device id to select a proper driver. In the pervious device registration logic, since the live migration operation ops of the three accelerator devices is the same. Therefore, only one driver entity will be registered. As a result, only the first sec will be loaded successfully, while hpre and zip cannot be loaded. The acc live migration driver needs to be adapted. Tips: The problem code is not completely fixed. To keep consistent with olk-5.10, roll back the previous bugfix and resubmit a new one. This new bugfix is consistent with the one for the olk-5.10 branch. Signed-off-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> Link:https://gitee.com/openeuler/kernel/pulls/1700 Reviewed-by: Zenghui Yu <yuzenghui@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/1676 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 08 8月, 2023 5 次提交
-
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7QPGW CVE: NA ------------------------------------------------------------------ In probe_vendor_drivers, all registered vendor drivers are traversed. This is not a good idea. If a vendor driver is not implemented well enough, it may cause the system to panic. Use the vendor id and device id to select a proper driver. In the pervious device registration logic, since the live migration operation ops of the three accelerator devices is the same. Therefore, only one driver entity will be registered. As a result, only the first sec will be loaded successfully, while hpre and zip cannot be loaded. The acc live migration driver needs to be adapted. Tips: This bugfix is consistent with the one for the olk-5.10 branch. Signed-off-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7QPGW CVE: NA ------------------------------------------------------------------ This reverts commit 75fbddc8. The problem code is not completely fixed. To keep consistent with olk-5.10, roll back this patch and resubmit the bugfix. Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @stinft https://gitee.com/openeuler/kernel/issues/I7PDHP Link:https://gitee.com/openeuler/kernel/pulls/1651 Reviewed-by: Chengchang Tang <tangchengchang@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/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/1643 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/1645 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 07 8月, 2023 2 次提交
-
-
由 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)
-
由 Chengchang Tang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PDHP --------------------------------------------------------------- The function hns_roce_dealloc_dfx_cnt() was omitted while uploading "RDMA/hns: Add dfx cnt stats". This patch fixes it. Fixes: d5a4ca75 ("RDMA/hns: Add dfx cnt stats") Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
-
- 04 8月, 2023 3 次提交
-
-
由 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)
-
由 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/1589 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/1584 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/1600 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/1603 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/1616 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 02 8月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1541 Backport 5.10.158 - 5.10.159 LTS patches from upstream. Conflicts: context confilict(4): 5e3d4a68e2e1: x86/tsx: Add a feature bit for TSX control MSR support 7c7075c88da4: rtc: mc146818: Prevent reading garbage 8bb5fe58305f: rtc: mc146818-lib: fix RTC presence check 3eecd2bc10e0: xen/netback: do some code cleanup Already merged(9): a2efc465245e: io_uring: don't hold uring_lock when calling io_run_task_work* 4aa32aaef6c1: proc: avoid integer type confusion in get_proc_long 9ba389863ac6: proc: proc_skip_spaces() shouldn't think it is working on C strings 83632fc41449: xen/netback: don't call kfree_skb() with interrupts disabled c42221efb115: can: af_can: fix NULL pointer dereference in can_rcv_filter 575a6266f63d: af_unix: Get user_ns from in_skb in unix_diag_get_exact(). 49e07c0768db: xen/netback: Ensure protocol headers don't fall in the non-linear area fccee93eb20d: mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page a00444e25bbc: xen/netback: fix build warning Rejected(1): f1f7f36cf682: memcg: fix possible use-after-free in memcg_write_event_control() Total patches: 193 - 9 -1 = 183 Link:https://gitee.com/openeuler/kernel/pulls/1579 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 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/1594 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 18 次提交
-
-
由 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)
-
由 Frank Jungclaus 提交于
stable inclusion from stable-v5.10.159 commit 4fd6f84e0a0c432d1acc56b7ae76e7676587081d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4fd6f84e0a0c432d1acc56b7ae76e7676587081d -------------------------------- [ Upstream commit 918ee491 ] We don't get any further EVENT from an esd CAN USB device for changes on REC or TEC while those counters converge to 0 (with ecc == 0). So when handling the "Back to Error Active"-event force txerr = rxerr = 0, otherwise the berr-counters might stay on values like 95 forever. Also, to make life easier during the ongoing development a netdev_dbg() has been introduced to allow dumping error events send by an esd CAN USB device. Fixes: 96d8e903 ("can: Add driver for esd CAN-USB/2 device") Signed-off-by: NFrank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20221130202242.3998219-2-frank.jungclaus@esd.eu Cc: stable@vger.kernel.org Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 82e4861c)
-
由 Emeel Hakim 提交于
stable inclusion from stable-v5.10.159 commit cf0e42310648a23188a411f7287dd95599086fce category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cf0e42310648a23188a411f7287dd95599086fce -------------------------------- [ Upstream commit 38099024 ] Add missing attribute validation for IFLA_MACSEC_OFFLOAD to the netlink policy. Fixes: 791bb3fc ("net: macsec: add support for specifying offload upon link creation") Signed-off-by: NEmeel Hakim <ehakim@nvidia.com> Reviewed-by: NJiri Pirko <jiri@nvidia.com> Reviewed-by: NSabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/20221207101618.989-1-ehakim@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 3208e0ec)
-
由 Dan Carpenter 提交于
stable inclusion from stable-v5.10.159 commit 6b03e41767c7125d36c2fc4b59dd3ccc5da0738e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b03e41767c7125d36c2fc4b59dd3ccc5da0738e -------------------------------- [ Upstream commit cdd97383 ] In an earlier commit, I added a bounds check to prevent an out of bounds read and a WARN(). On further discussion and consideration that check was probably too aggressive. Instead of returning -EINVAL, a better fix would be to just prevent the out of bounds read but continue the process. Background: The value of "pp->rxq_def" is a number between 0-7 by default, or even higher depending on the value of "rxq_number", which is a module parameter. If the value is more than the number of available CPUs then it will trigger the WARN() in cpu_max_bits_warn(). Fixes: e8b4fc13 ("net: mvneta: Prevent out of bounds read in mvneta_config_rss()") Signed-off-by: NDan Carpenter <error27@gmail.com> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/Y5A7d1E5ccwHTYPf@kadamSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 52664784)
-
由 Eric Dumazet 提交于
stable inclusion from stable-v5.10.159 commit 8208d7e56b1e579320b9ff3712739ad2e63e1f86 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8208d7e56b1e579320b9ff3712739ad2e63e1f86 -------------------------------- [ Upstream commit 803e8486 ] Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers. It seems to not be always true, at least for UDP stack. syzbot reported: BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 </TASK> Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 __sys_sendto+0x23a/0x340 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7599: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:511 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] kmem_cache_free+0xee/0x5c0 mm/slub.c:3683 dst_destroy+0x2ea/0x400 net/core/dst.c:127 rcu_do_batch kernel/rcu/tree.c:2250 [inline] rcu_core+0x81f/0x1980 kernel/rcu/tree.c:2510 __do_softirq+0x1fb/0xadc kernel/softirq.c:571 Last potentially related work creation: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481 call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798 dst_release net/core/dst.c:177 [inline] dst_release+0x7d/0xe0 net/core/dst.c:167 refdst_drop include/net/dst.h:256 [inline] skb_dst_drop include/net/dst.h:268 [inline] skb_release_head_state+0x250/0x2a0 net/core/skbuff.c:838 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x151/0x4b0 net/core/skbuff.c:891 kfree_skb_list_reason+0x4b/0x70 net/core/skbuff.c:901 kfree_skb_list include/linux/skbuff.h:1227 [inline] ip6_fragment+0x2026/0x2770 net/ipv6/ip6_output.c:949 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Second to last potentially related work creation: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:481 call_rcu+0x9d/0x820 kernel/rcu/tree.c:2798 dst_release net/core/dst.c:177 [inline] dst_release+0x7d/0xe0 net/core/dst.c:167 refdst_drop include/net/dst.h:256 [inline] skb_dst_drop include/net/dst.h:268 [inline] __dev_queue_xmit+0x1b9d/0x3ba0 net/core/dev.c:4211 dev_queue_xmit include/linux/netdevice.h:3008 [inline] neigh_resolve_output net/core/neighbour.c:1552 [inline] neigh_resolve_output+0x51b/0x840 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:546 [inline] ip6_finish_output2+0x56c/0x1530 net/ipv6/ip6_output.c:134 __ip6_finish_output net/ipv6/ip6_output.c:195 [inline] ip6_finish_output+0x694/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] mld_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820 mld_send_cr net/ipv6/mcast.c:2121 [inline] mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 The buggy address belongs to the object at ffff88801d403dc0 which belongs to the cache ip6_dst_cache of size 240 The buggy address is located 192 bytes inside of 240-byte region [ffff88801d403dc0, ffff88801d403eb0) The buggy address belongs to the physical page: page:ffffea00007500c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d403 memcg:ffff888022f49c81 flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000200 ffffea0001ef6580 dead000000000002 ffff88814addf640 raw: 0000000000000000 00000000800c000c 00000001ffffffff ffff888022f49c81 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_HARDWALL), pid 3719, tgid 3719 (kworker/0:6), ts 136223432244, free_ts 136222971441 prep_new_page mm/page_alloc.c:2539 [inline] get_page_from_freelist+0x10b5/0x2d50 mm/page_alloc.c:4288 __alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5555 alloc_pages+0x1aa/0x270 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x213/0x300 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0xa91/0x1400 mm/slub.c:3180 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279 slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x31a/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 icmp6_dst_alloc+0x71/0x680 net/ipv6/route.c:3261 mld_sendpack+0x5de/0xe70 net/ipv6/mcast.c:1809 mld_send_cr net/ipv6/mcast.c:2121 [inline] mld_ifc_work+0x720/0xdc0 net/ipv6/mcast.c:2653 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1459 [inline] free_pcp_prepare+0x65c/0xd90 mm/page_alloc.c:1509 free_unref_page_prepare mm/page_alloc.c:3387 [inline] free_unref_page+0x1d/0x4d0 mm/page_alloc.c:3483 __unfreeze_partials+0x17c/0x1a0 mm/slub.c:2586 qlink_free mm/kasan/quarantine.c:168 [inline] qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187 kasan_quarantine_reduce+0x184/0x210 mm/kasan/quarantine.c:294 __kasan_slab_alloc+0x66/0x90 mm/kasan/common.c:302 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] kmem_cache_alloc_node+0x304/0x410 mm/slub.c:3443 __alloc_skb+0x214/0x300 net/core/skbuff.c:497 alloc_skb include/linux/skbuff.h:1267 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1191 [inline] netlink_sendmsg+0x9a6/0xe10 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 __sys_sendto+0x23a/0x340 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xe1/0x1b0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 1758fd46 ("ipv6: remove unnecessary dst_hold() in ip6_fragment()") Reported-by: syzbot+8c0ac31aa9681abb9e2d@syzkaller.appspotmail.com Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Wei Wang <weiwan@google.com> Cc: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/r/20221206101351.2037285-1-edumazet@google.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 55c08155)
-
由 Yang Yingliang 提交于
stable inclusion from stable-v5.10.159 commit 3d59adad126d0f22e06506449f530fcc16277e61 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3d59adad126d0f22e06506449f530fcc16277e61 -------------------------------- [ Upstream commit 7d8c19bf ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with interrupts being disabled. So replace kfree_skb/dev_kfree_skb() with dev_kfree_skb_irq() and dev_consume_skb_irq() under spin_lock_irq(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NJiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20221207015310.2984909-1-yangyingliang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 3bd674f7)
-
由 Zhang Changzhong 提交于
stable inclusion from stable-v5.10.159 commit 87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5 -------------------------------- [ Upstream commit 063a932b ] The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only. Fixes: d4c41139 ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver") Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: NLeon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/1670134149-29516-1-git-send-email-zhangchangzhong@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit c3862675)
-
由 Xin Long 提交于
stable inclusion from stable-v5.10.159 commit cc668fddde4262f608baca2c9d85b9cf333e41c3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc668fddde4262f608baca2c9d85b9cf333e41c3 -------------------------------- [ Upstream commit 88956177 ] When sending packets between nodes in netns, it calls tipc_lxc_xmit() for peer node to receive the packets where tipc_sk_mcast_rcv()/tipc_sk_rcv() might be called, and it's pretty much like in tipc_rcv(). Currently the local 'node rw lock' is held during calling tipc_lxc_xmit() to protect the peer_net not being freed by another thread. However, when receiving these packets, tipc_node_add_conn() might be called where the peer 'node rw lock' is acquired. Then a dead lock warning is triggered by lockdep detector, although it is not a real dead lock: WARNING: possible recursive locking detected -------------------------------------------- conn_server/1086 is trying to acquire lock: ffff8880065cb020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_add_conn.cold.76+0xaa/0x211 [tipc] but task is already holding lock: ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_xmit+0x285/0xb30 [tipc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&n->lock#2); lock(&n->lock#2); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by conn_server/1086: #0: ffff8880036d1e40 (sk_lock-AF_TIPC){+.+.}-{0:0}, \ at: tipc_accept+0x9c0/0x10b0 [tipc] #1: ffff8880036d5f80 (sk_lock-AF_TIPC/1){+.+.}-{0:0}, \ at: tipc_accept+0x363/0x10b0 [tipc] #2: ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \ at: tipc_node_xmit+0x285/0xb30 [tipc] #3: ffff888012e13370 (slock-AF_TIPC){+...}-{2:2}, \ at: tipc_sk_rcv+0x2da/0x1b40 [tipc] Call Trace: <TASK> dump_stack_lvl+0x44/0x5b __lock_acquire.cold.77+0x1f2/0x3d7 lock_acquire+0x1d2/0x610 _raw_write_lock_bh+0x38/0x80 tipc_node_add_conn.cold.76+0xaa/0x211 [tipc] tipc_sk_finish_conn+0x21e/0x640 [tipc] tipc_sk_filter_rcv+0x147b/0x3030 [tipc] tipc_sk_rcv+0xbb4/0x1b40 [tipc] tipc_lxc_xmit+0x225/0x26b [tipc] tipc_node_xmit.cold.82+0x4a/0x102 [tipc] __tipc_sendstream+0x879/0xff0 [tipc] tipc_accept+0x966/0x10b0 [tipc] do_accept+0x37d/0x590 This patch avoids this warning by not holding the 'node rw lock' before calling tipc_lxc_xmit(). As to protect the 'peer_net', rcu_read_lock() should be enough, as in cleanup_net() when freeing the netns, it calls synchronize_rcu() before the free is continued. Also since tipc_lxc_xmit() is like the RX path in tipc_rcv(), it makes sense to call it under rcu_read_lock(). Note that the right lock order must be: rcu_read_lock(); tipc_node_read_lock(n); tipc_node_read_unlock(n); tipc_lxc_xmit(); rcu_read_unlock(); instead of: tipc_node_read_lock(n); rcu_read_lock(); tipc_node_read_unlock(n); tipc_lxc_xmit(); rcu_read_unlock(); and we have to call tipc_node_read_lock/unlock() twice in tipc_node_xmit(). Fixes: f73b1281 ("tipc: improve throughput between nodes in netns") Reported-by: NShuang Li <shuali@redhat.com> Signed-off-by: NXin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/5bdd1f8fee9db695cfff4528a48c9b9d0523fb00.1670110641.git.lucien.xin@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 30d020f3)
-
由 Zhengchao Shao 提交于
stable inclusion from stable-v5.10.159 commit 4be43e46c3f945fc7dd9e23c73a7a66927a3b814 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4be43e46c3f945fc7dd9e23c73a7a66927a3b814 -------------------------------- [ Upstream commit 78a9ea43 ] When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. Fixes: bf425b82 ("net: dsa: sja1105: expose static config as devlink region") Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221205012132.2110979-1-shaozhengchao@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 9c81b638)
-
由 Ido Schimmel 提交于
stable inclusion from stable-v5.10.159 commit 8e3f9ac00956442ecfbdd4e6c5c731b8ab6f77a0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8e3f9ac00956442ecfbdd4e6c5c731b8ab6f77a0 -------------------------------- [ Upstream commit c0d99934 ] Cited commit added the table ID to the FIB info structure, but did not properly initialize it when table ID 0 is used. This can lead to a route in the default VRF with a preferred source address not being flushed when the address is deleted. Consider the following example: # ip address add dev dummy1 192.0.2.1/28 # ip address add dev dummy1 192.0.2.17/28 # ip route add 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 100 # ip route add table 0 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 200 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 100 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Both routes are installed in the default VRF, but they are using two different FIB info structures. One with a metric of 100 and table ID of 254 (main) and one with a metric of 200 and table ID of 0. Therefore, when the preferred source address is deleted from the default VRF, the second route is not flushed: # ip address del dev dummy1 192.0.2.17/28 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Fix by storing a table ID of 254 instead of 0 in the route configuration structure. Add a test case that fails before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [FAIL] Tests passed: 8 Tests failed: 1 And passes after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [ OK ] Tests passed: 9 Tests failed: 0 Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Reported-by: NDonald Sharp <sharpd@nvidia.com> Signed-off-by: NIdo Schimmel <idosch@nvidia.com> Reviewed-by: NDavid Ahern <dsahern@kernel.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit dd2ab3c3)
-
由 Ido Schimmel 提交于
stable inclusion from stable-v5.10.159 commit 5211e5ff9ddc67e2cbd5af78e09b8e7d85ca95f2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5211e5ff9ddc67e2cbd5af78e09b8e7d85ca95f2 -------------------------------- [ Upstream commit f96a3d74 ] Cited commit added the table ID to the FIB info structure, but did not prevent structures with different table IDs from being consolidated. This can lead to routes being flushed from a VRF when an address is deleted from a different VRF. Fix by taking the table ID into account when looking for a matching FIB info. This is already done for FIB info structures backed by a nexthop object in fib_find_info_nh(). Add test cases that fail before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [FAIL] TEST: Route in default VRF not removed [ OK ] RTNETLINK answers: File exists TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [FAIL] Tests passed: 6 Tests failed: 2 And pass after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Tests passed: 8 Tests failed: 0 Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Signed-off-by: NIdo Schimmel <idosch@nvidia.com> Reviewed-by: NDavid Ahern <dsahern@kernel.org> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit ef22f90f)
-
由 YueHaibing 提交于
stable inclusion from stable-v5.10.159 commit 36e248269a16bd872631b76d4f0ec710f84e140d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=36e248269a16bd872631b76d4f0ec710f84e140d -------------------------------- [ Upstream commit 743117a9 ] Fix the potential risk of OOB if skb_linearize() fails in tipc_link_proto_rcv(). Fixes: 5cbb28a4 ("tipc: linearize arriving NAME_DISTR and LINK_PROTO buffers") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20221203094635.29024-1-yuehaibing@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit b9c2530e)
-
由 Liu Jian 提交于
stable inclusion from stable-v5.10.159 commit 93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc -------------------------------- [ Upstream commit 433c07a1 ] The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. Fixes: 57c5bc9a ("net: hisilicon: add hix5hd2 mac driver") Signed-off-by: NLiu Jian <liujian56@huawei.com> Link: https://lore.kernel.org/r/20221203094240.1240211-2-liujian56@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit afce65fe)
-
由 Liu Jian 提交于
stable inclusion from stable-v5.10.159 commit 296a50aa8b2982117520713edc1375777a9f8506 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=296a50aa8b2982117520713edc1375777a9f8506 -------------------------------- [ Upstream commit 46401770 ] The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. Fixes: 542ae60a ("net: hisilicon: Add Fast Ethernet MAC driver") Signed-off-by: NLiu Jian <liujian56@huawei.com> Link: https://lore.kernel.org/r/20221203094240.1240211-1-liujian56@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 4d7c9d6a)
-
由 Yongqiang Liu 提交于
stable inclusion from stable-v5.10.159 commit 8d1aed7a117a114707dd04a63fddc7fdcce18132 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8d1aed7a117a114707dd04a63fddc7fdcce18132 -------------------------------- [ Upstream commit 42330a32 ] The nicvf_probe() won't destroy workqueue when register_netdev() failed. Add destroy_workqueue err handle case to fix this issue. Fixes: 2ecbe4f4 ("net: thunderx: replace global nicvf_rx_mode_wq work queue for all VFs to private for each of them.") Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com> Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20221203094125.602812-1-liuyongqiang13@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit ac403e1d)
-
由 Hangbin Liu 提交于
stable inclusion from stable-v5.10.159 commit a5cfbc199536d853abd45a9105fe097202c4f0ca category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a5cfbc199536d853abd45a9105fe097202c4f0ca -------------------------------- [ Upstream commit ee496694 ] Although the type I ERSPAN is based on the barebones IP + GRE encapsulation and no extra ERSPAN header. Report erspan version on GRE interface looks unreasonable. Fix this by separating the erspan and gre fill info. IPv6 GRE does not have this info as IPv6 only supports erspan version 1 and 2. Reported-by: NJianlin Shi <jishi@redhat.com> Fixes: f989d546 ("erspan: Add type I version 0 support.") Signed-off-by: NHangbin Liu <liuhangbin@gmail.com> Acked-by: NWilliam Tu <u9012063@gmail.com> Link: https://lore.kernel.org/r/20221203032858.3130339-1-liuhangbin@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 8e1c3cbc)
-