- Oct 31, 2022
-
-
openeuler-ci-bot authored
Merge Pull Request from: @CTC-XiboWang This PR is cherry-pick from upstream "x86/apic/vector: Fix ordering in vector assignment" Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/apic?id=190113b4c6531c8e09b31d5235f9b5175cbb0f72 Link:https://gitee.com/openeuler/kernel/pulls/192 Reviewed-by:
Laibin Qiu <qiulaibin@huawei.com> Reviewed-by:
Jun Tian <jun.j.tian@intel.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
- Oct 29, 2022
-
-
Ryusuke Konishi authored
mainline inclusion from mainline-v6.1-rc1 commit d0d51a97063db4704a5ef6bc978dddab1636a306 category: bugfix bugzilla: 187884, https://gitee.com/src-openeuler/kernel/issues/I5X2OB CVE: CVE-2022-3646 -------------------------------- If nilfs_attach_log_writer() failed to create a log writer thread, it frees a data structure of the log writer without any cleanup. After commit e912a5b6 ("nilfs2: use root object to get ifile"), this causes a leak of struct nilfs_root, which started to leak an ifile metadata inode and a kobject on that struct. In addition, if the kernel is booted with panic_on_warn, the above ifile metadata inode leak will cause the following panic when the nilfs2 kernel module is removed: kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when called from nilfs_destroy_cachep+0x16/0x3a [nilfs2] WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140 ... RIP: 0010...
-
Peilin Ye authored
stable inclusion from stable-v4.19.256 commit 2fc2a7767f661e6083f69588718cdf6f07cb9330 category: bugfix bugzilla: 187891, https://gitee.com/src-openeuler/kernel/issues/I5WYLL CVE: CVE-2022-3629 -------------------------------- commit 7e97cfed9929eaabc41829c395eb0d1350fccb9d upstream. An O_NONBLOCK vsock_connect() request may try to reschedule @connect_work. Imagine the following sequence of vsock_connect() requests: 1. The 1st, non-blocking request schedules @connect_work, which will expire after 200 jiffies. Socket state is now SS_CONNECTING; 2. Later, the 2nd, blocking request gets interrupted by a signal after a few jiffies while waiting for the connection to be established. Socket state is back to SS_UNCONNECTED, but @connect_work is still pending, and will expire after 100 jiffies. 3. Now, the 3rd, non-blocking request tries to schedule @connect_work again. Since @connect_work is already scheduled, schedule_delayed...
-
- Oct 27, 2022
-
-
Toke Høiland-Jørgensen authored
stable inclusion from stable-v4.19.258 commit 5dac9b60b48ce8a3cd498c5680e8b5f0f4034461 category: bugfix bugzilla: 187862, https://gitee.com/src-openeuler/kernel/issues/I5WF14 CVE: CVE-2022-3586 -------------------------------- [ Upstream commit 2f09707d0c972120bf794cfe0f0c67e2c2ddb252 ] Cong Wang noticed that the previous fix for sch_sfb accessing the queued skb after enqueueing it to a child qdisc was incomplete: the SFB enqueue function was also calling qdisc_qstats_backlog_inc() after enqueue, which reads the pkt len from the skb cb field. Fix this by also storing the skb len, and using the stored value to increment the backlog after enqueueing. Fixes: 9efd23297cca ("sch_sfb: Don't assume the skb is still around after enqueueing to child") Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> Acked-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20220905192137.965549-1-toke@toke.dk Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com> Reviewed-by:
chenweilong <chenweilong@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Toke Høiland-Jørgensen authored
stable inclusion from stable-v4.19.258 commit 9245ed20950afe225bc6d1c4b9d28d55aa152e25 category: bugfix bugzilla: 187862, https://gitee.com/src-openeuler/kernel/issues/I5WF14 CVE: CVE-2022-3586 -------------------------------- [ Upstream commit 9efd23297cca530bb35e1848665805d3fcdd7889 ] The sch_sfb enqueue() routine assumes the skb is still alive after it has been enqueued into a child qdisc, using the data in the skb cb field in the increment_qlen() routine after enqueue. However, the skb may in fact have been freed, causing a use-after-free in this case. In particular, this happens if sch_cake is used as a child of sfb, and the GSO splitting mode of CAKE is enabled (in which case the skb will be split into segments and the original skb freed). Fix this by copying the sfb cb data to the stack before enqueueing the skb, and using this stack copy in increment_qlen() instead of the skb pointer itself. Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231 Fixes: e13e02a3 ("net_sched: SFB flow scheduler") Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com> Reviewed-by:
chenweilong <chenweilong@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Kuniyuki Iwashima authored
mainline inclusion from mainline-6.1-rc1 commit 364f997b5cfe1db0d63a390fe7c801fa2b3115f6 category: bugfix bugzilla: 187846, https://gitee.com/src-openeuler/kernel/issues/I5W7YP CVE: CVE-2022-3567 --------------------------- Commit 086d49058cd8 ("ipv6: annotate some data-races around sk->sk_prot") fixed some data-races around sk->sk_prot but it was not enough. Some functions in inet6_(stream|dgram)_ops still access sk->sk_prot without lock_sock() or rtnl_lock(), so they need READ_ONCE() to avoid load tearing. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Conflicts: net/ipv6/ipv6_sockglue.c Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Eric Dumazet authored
mainline inclusion from mainline-v6.1-rc1 commit 086d49058cd8471046ae9927524708820f5fd1c7 category: bugfix bugzilla: 187846, https://gitee.com/src-openeuler/kernel/issues/I5W7YP CVE: CVE-2022-3567 --------------------------- IPv6 has this hack changing sk->sk_prot when an IPv6 socket is 'converted' to an IPv4 one with IPV6_ADDRFORM option. This operation is only performed for TCP and UDP, knowing their 'struct proto' for the two network families are populated in the same way, and can not disappear while a reader might use and dereference sk->sk_prot. If we think about it all reads of sk->sk_prot while either socket lock or RTNL is not acquired should be using READ_ONCE(). Also note that other layers like MPTCP, XFRM, CHELSIO_TLS also write over sk->sk_prot. BUG: KCSAN: data-race in inet6_recvmsg / ipv6_setsockopt write to 0xffff8881386f7aa8 of 8 bytes by task 26932 on cpu 0: do_ipv6_setsockopt net/ipv6/ipv6_sockglue.c:492 [inline] ipv6_setsockopt+0x3758/0x3910 net/ipv6/ipv6_sockglue.c:1019 udpv6_setsockopt+0x85/0x90 net/ipv6/udp.c:1649 sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3489 __sys_setsockopt+0x209/0x2a0 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff8881386f7aa8 of 8 bytes by task 26911 on cpu 1: inet6_recvmsg+0x7a/0x210 net/ipv6/af_inet6.c:659 ____sys_recvmsg+0x16c/0x320 ___sys_recvmsg net/socket.c:2674 [inline] do_recvmmsg+0x3f5/0xae0 net/socket.c:2768 __sys_recvmmsg net/socket.c:2847 [inline] __do_sys_recvmmsg net/socket.c:2870 [inline] __se_sys_recvmmsg net/socket.c:2863 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2863 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffffffff85e0e980 -> 0xffffffff85e01580 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 26911 Comm: syz-executor.3 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Conflicts: net/ipv6/af_inet6.c net/ipv6/ipv6_sockglue.c Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Paolo Abeni authored
mainline inclusion from mainline-v5.3-rc1 commit 68ab5d14 category: bugfix bugzilla: 187846, https://gitee.com/src-openeuler/kernel/issues/I5W7YP CVE: CVE-2022-3567 --------------------------- This will simplify indirect call wrapper invocation in the following patch. No functional change intended, any - out-of-tree - IPv6 user of inet_{recv,send}msg can keep using the existing functions. SCTP code still uses the existing version even for ipv6: as this series will not add ICW for SCTP, moving to the new helper would not give any benefit. The only other in-kernel user of inet_{recv,send}msg is pvcalls_conn_back_read(), but psvcalls explicitly creates only IPv4 socket, so no need to update that code path, too. v1 -> v2: drop inet6_{recv,send}msg declaration from header file, prefer ICW macro instead Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Paolo Abeni authored
mainline inclusion from mainline-v5.3-rc1 commit e4730936 category: bugfix bugzilla: 187846, https://gitee.com/src-openeuler/kernel/issues/I5W7YP CVE: CVE-2022-3567 --------------------------- The same code is replicated verbatim in multiple places, and the next patches will introduce an additional user for it. Factor out a helper and use it where appropriate. No functional change intended. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Thomas Gleixner authored
mainline inclusion from v5.10 commit 190113b4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Y4BR CVE: NA ------------------------------------------- Prarit reported that depending on the affinity setting the ' irq $N: Affinity broken due to vector space exhaustion.' message is showing up in dmesg, but the vector space on the CPUs in the affinity mask is definitely not exhausted. Shung-Hsi provided traces and analysis which pinpoints the problem: The ordering of trying to assign an interrupt vector in assign_irq_vector_any_locked() is simply wrong if the interrupt data has a valid node assigned. It does: 1) Try the intersection of affinity mask and node mask 2) Try the node mask 3) Try the full affinity mask 4) Try the full online mask Obviously #2 and #3 are in the wrong order as the requested affinity mask has to take precedence. In the observed cases #1 failed because the affinity m...
-
Ryusuke Konishi authored
mainline inclusion from mainline-v6.1-rc1 commit d325dc6eb763c10f591c239550b8c7e5466a5d09 category: bugfix bugzilla: 187877,https://gitee.com/src-openeuler/kernel/issues/I5X3MX CVE: CVE-2022-3649 -------------------------------- If the beginning of the inode bitmap area is corrupted on disk, an inode with the same inode number as the root inode can be allocated and fail soon after. In this case, the subsequent call to nilfs_clear_inode() on that bogus root inode will wrongly decrement the reference counter of struct nilfs_root, and this will erroneously free struct nilfs_root, causing kernel oopses. This fixes the problem by changing nilfs_new_inode() to skip reserved inode numbers while repairing the inode bitmap. Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.com Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by:
<syzbot+b8c672b0e22615c80fe0@syzkaller.appspotmail.com> Reported-by:
Khalid Masum <khalid.masum.92@gmail.com> Tested-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Conflict: fs/nilfs2/inode.c Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Oct 25, 2022
-
-
Jialiang Wang authored
mainline inclusion from mainline-v6.0-rc1 commit 02e1a114fdb71e59ee6770294166c30d437bf86a category: bugfix bugzilla: 187867, https://gitee.com/src-openeuler/kernel/issues/I5W7B5 CVE: CVE-2022-3545 -------------------------------- area_cache_get() is used to distribute cache->area and set cache->id, and if cache->id is not 0 and cache->area->kref refcount is 0, it will release the cache->area by nfp_cpp_area_release(). area_cache_get() set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire(). But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is is already set but the refcount is not increased as expected. At this time, calling the nfp_cpp_area_release() will cause use-after-free. To avoid the use-after-free, set cache->id after area_init() and nfp_cpp_area_acquire() complete successfully. Note: This vulnerability is triggerable by providing emulated device equipped with specified configuration. BUG: KASAN: use-after-free ...
-
Duoming Zhou authored
mainline inclusion from mainline-v6.1-rc1 commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7YH CVE: CVE-2022-3565 -------------------------------- The l1oip_cleanup() traverses the l1oip_ilist and calls release_card() to cleanup module and stack. However, release_card() calls del_timer() to delete the timers such as keep_tl and timeout_tl. If the timer handler is running, the del_timer() will not stop it and result in UAF bugs. One of the processes is shown below: (cleanup routine) | (timer handler) release_card() | l1oip_timeout() ... | del_timer() | ... ... | kfree(hc) //FREE | | hc->timeout_on = 0 //USE Fix by calling del_timer_sync() in release_card(), which makes sure the timer handlers have finished before the resources, such as l1oip and so on, have been deallocated. What's more, the hc->workq and hc->socket_thread can kick those timers right back in. We add a bool flag to show if card is released. Then, check this flag in hc->workq and hc->socket_thread. Fixes: 3712b42d ("Add layer1 over IP support") Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
GUO Zihua <guozihua@huawei.com> Reviewed-by:
GONG Ruiqi <gongruiqi1@huawei.com> Reviewed-by:
Wang Weiyang <wangweiyang2@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Kuniyuki Iwashima authored
mainline inclusion from mainline-v6.1-rc1 commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7ZF CVE: CVE-2022-3566 -------------------------------- setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops under lock_sock(), but tcp_(get|set)sockopt() read it locklessly. To avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE() for the reads and writes. Thanks to Eric Dumazet for providing the syzbot report: BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect write to 0xffff88813c624518 of 8 bytes by task 23936 on cpu 0: tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240 __inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660 inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724 __sys_connect_file net/socket.c:1976 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1993 __do_sys_connect net/socket.c:2003 [inline] __se_sys_connect net/socket.c:2000 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:2000 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff88813c624518 of 8 bytes by task 23937 on cpu 1: tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789 sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585 __sys_setsockopt+0x212/0x2b0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0x62/0x70 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffffffff8539af68 -> 0xffffffff8539aff8 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted 6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
syzbot <syzkaller@googlegroups.com> Reported-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Conflicts: net/ipv4/tcp.c net/ipv6/ipv6_sockglue.c net/ipv6/tcp_ipv6.c Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Maxim Mikityanskiy authored
mainline inclusion from bluetooth-next commit 89f9f3cb86b1c63badaf392a83dd661d56cc50b1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7XW CVE: CVE-2022-3564 -------------------------------- Fix the race condition between the following two flows that run in parallel: 1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb. 2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram. An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2cap_reassemble_sdu can't use the SKB after that function returns. However, some places continue accessing struct l2cap_ctrl that resides in the SKB's CB for a short time after l2cap_reassemble_sdu returns, leading to a use-after-free condition (the stack trace is below, line numbers for kernel 5.19.8). Fix it by keeping a local copy of struct l2cap_ctrl. BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169 Workqueue: hci0 hci_rx_work [bluetooth] Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth ret_from_fork (arch/x86/entry/entry_64.S:306) </TASK> Allocated by task 43169: kasan_save_stack (mm/kasan/common.c:39) __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) __alloc_skb (net/core/skbuff.c:414) l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth process_one_work (kernel/workqueue.c:2289) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) ret_from_fork (arch/x86/entry/entry_64.S:306) Freed by task 27920: kasan_save_stack (mm/kasan/common.c:39) kasan_set_track (mm/kasan/common.c:45) kasan_set_free_info (mm/kasan/generic.c:372) ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328) slab_free_freelist_hook (mm/slub.c:1780) kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553) skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth sock_read_iter (net/socket.c:1087) new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401) vfs_read (fs/read_write.c:482) ksys_read (fs/read_write.c:620) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u Fixes: d2a7ac5d ("Bluetooth: Add the ERTM receive state machine") Fixes: 4b51dae9 ("Bluetooth: Add streaming mode receive and incoming packet classifier") Signed-off-by:
Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> conflicts: net/bluetooth/l2cap_core.c Signed-off-by:
Xia Longlong <xialonglong1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
openeuler-ci-bot authored
Merge Pull Request from: @babyihc This PR is cherry-pick from upstream "scsi: megaraid_sas: Add support for MegaRAID Aero controllers" Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=469f72ddc618d0afe05176b18ae6ebefb1fc6fe2 Link:https://gitee.com/openeuler/kernel/pulls/134 Reviewed-by:
Laibin Qiu <qiulaibin@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
openeuler-ci-bot authored
Merge Pull Request from: @babyihc This PR is cherry-pick from upstream "vfio-pci: Mask cap zero" Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc138db1b96264b9c1779cf18d5a3b186aa90066 Link:https://gitee.com/openeuler/kernel/pulls/138 Reviewed-by:
Laibin Qiu <qiulaibin@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
- Oct 24, 2022
-
-
Jianglei Nie authored
mainline inclusion from mainline-v6.1-rc1 commit b43f9acbb8942b05252be83ac25a81cec70cc192 category: bugfix bugzilla: 187839, https://gitee.com/src-openeuler/kernel/issues/I5W7B1 CVE: CVE-2022-3542 -------------------------------- bnx2x_tpa_stop() allocates a memory chunk from new_data with bnx2x_frag_alloc(). The new_data should be freed when gets some error. But when "pad + len > fp->rx_buf_size" is true, bnx2x_tpa_stop() returns without releasing the new_data, which will lead to a memory leak. We should free the new_data with bnx2x_frag_free() when "pad + len > fp->rx_buf_size" is true. Fixes: 07b0f009 ("bnx2x: fix possible panic under memory stress") Signed-off-by:
Jianglei Nie <niejianglei2021@163.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ren Zhijie <renzhijie2@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Oct 21, 2022
-
-
Andrew Gaul authored
mainline inclusion from mainline-v6.1-rc1 commit 93e2be344a7db169b7119de21ac1bf253b8c6907 category: bugfix bugzilla: 187847, https://gitee.com/src-openeuler/kernel/issues/I5WFKR CVE: CVE-2022-3594 -------------------------------- My system shows almost 10 million of these messages over a 24-hour period which pollutes my logs. Signed-off-by:
Andrew Gaul <gaul@google.com> Link: https://lore.kernel.org/r/20221002034128.2026653-1-gaul@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Lu Wei <luwei32@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Wang Weiyang <wangweiyang2@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Shivasharan S authored
mainline inclusion from mainline-v5.0 commit 469f72dd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5WW82 CVE: NA -------------------------------- This patch adds support for MegaRAID Aero controller PCI IDs. Print a message when a configurable secure type controller is encountered. Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-
Alex Williamson authored
mainline inclusion from mainline-v5.8 commit bc138db1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5WW3D CVE: NA -------------------------------- The PCI Code and ID Assignment Specification changed capability ID 0 from reserved to a NULL capability in the v1.1 revision. The NULL capability is defined to include only the 16-bit capability header, ie. only the ID and next pointer. Unfortunately vfio-pci creates a map of config space, where ID 0 is used to reserve the standard type 0 header. Finding an actual capability with this ID therefore results in a bogus range marked in that map and conflicts with subsequent capabilities. As this seems to be a dummy capability anyway and we already support dropping capabilities, let's hide this one rather than delving into the potentially subtle dependencies within our map. Seen on an NVIDIA Tesla T4. Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-
- Oct 20, 2022
-
-
Kuniyuki Iwashima authored
mainline inclusion from mainline-v6.1-rc1 commit 3c52c6bb831f6335c176a0fc7214e26f43adbd11 category: bugfix bugzilla: 187825, https://gitee.com/src-openeuler/kernel/issues/I5VZ0J CVE: CVE-2022-3524 -------------------------------- syzbot reported a memory leak [0] related to IPV6_ADDRFORM. The scenario is that while one thread is converting an IPv6 socket into IPv4 with IPV6_ADDRFORM, another thread calls do_ipv6_setsockopt() and allocates memory to inet6_sk(sk)->XXX after conversion. Then, the converted sk with (tcp|udp)_prot never frees the IPv6 resources, which inet6_destroy_sock() should have cleaned up. setsockopt(IPV6_ADDRFORM) setsockopt(IPV6_DSTOPTS) +-----------------------+ +----------------------+ - do_ipv6_setsockopt(sk, ...) - sockopt_lock_sock(sk) - do_ipv6_setsockopt(sk, ...) - lock_sock(sk) ^._ called via tcpv6_prot - WRITE_ONCE(sk->sk_prot, &tcp_prot) before WRITE_ONCE() - xchg(&np->opt, NULL) - txopt_put(opt) - sockopt_release_sock(sk) - release_sock(sk) - sockopt_lock_sock(sk) - lock_sock(sk) - ipv6_set_opt_hdr(sk, ...) - ipv6_update_options(sk, opt) - xchg(&inet6_sk(sk)->opt, opt) ^._ opt is never freed. - sockopt_release_sock(sk) - release_sock(sk) Since IPV6_DSTOPTS allocates options under lock_sock(), we can avoid this memory leak by testing whether sk_family is changed by IPV6_ADDRFORM after acquiring the lock. This issue exists from the initial commit between IPV6_ADDRFORM and IPV6_PKTOPTIONS. [0]: BUG: memory leak unreferenced object 0xffff888009ab9f80 (size 96): comm "syz-executor583", pid 328, jiffies 4294916198 (age 13.034s) hex dump (first 32 bytes): 01 00 00 00 48 00 00 00 08 00 00 00 00 00 00 00 ....H........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000002ee98ae1>] kmalloc include/linux/slab.h:605 [inline] [<000000002ee98ae1>] sock_kmalloc+0xb3/0x100 net/core/sock.c:2566 [<0000000065d7b698>] ipv6_renew_options+0x21e/0x10b0 net/ipv6/exthdrs.c:1318 [<00000000a8c756d7>] ipv6_set_opt_hdr net/ipv6/ipv6_sockglue.c:354 [inline] [<00000000a8c756d7>] do_ipv6_setsockopt.constprop.0+0x28b7/0x4350 net/ipv6/ipv6_sockglue.c:668 [<000000002854d204>] ipv6_setsockopt+0xdf/0x190 net/ipv6/ipv6_sockglue.c:1021 [<00000000e69fdcf8>] tcp_setsockopt+0x13b/0x2620 net/ipv4/tcp.c:3789 [<0000000090da4b9b>] __sys_setsockopt+0x239/0x620 net/socket.c:2252 [<00000000b10d192f>] __do_sys_setsockopt net/socket.c:2263 [inline] [<00000000b10d192f>] __se_sys_setsockopt net/socket.c:2260 [inline] [<00000000b10d192f>] __x64_sys_setsockopt+0xbe/0x160 net/socket.c:2260 [<000000000a80d7aa>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<000000000a80d7aa>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<000000004562b5c6>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Wang Weiyang <wangweiyang2@huawei.com> Reviewed-by:
Liu Jian <liujian56@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
mainline inclusion from mainline-v6.0-rc7 commit 0152dfee235e87660f52a117fc9f70dc55956bb4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7AX CVE: CVE-2022-3535 -------------------------------- When mvpp2 is unloaded, the driver specific debugfs directory is not removed, which technically leads to a memory leak. However, this directory is only created when the first device is probed, so the hardware is present. Removing the module is only something a developer would to when e.g. testing out changes, so the module would be reloaded. So this memory leak is minor. The original attempt in commit fe2c9c61f668 ("net: mvpp2: debugfs: fix memory leak when using debugfs_lookup()") that was labelled as a memory leak fix was not, it fixed a refcount leak, but in doing so created a problem when the module is reloaded - the directory already exists, but mvpp2_root is NULL, so we lose all debugfs entries. This fix has been reverted. This is the alternative fix, where we remove the offending directory whenever the driver is unloaded. Fixes: 21da57a2 ("net: mvpp2: add a debugfs interface for the Header Parser") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/E1ofOAB-00CzkG-UO@rmk-PC.armlinux.org.uk Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Conflicts: drivers/net/ethernet/marvell/mvpp2/mvpp2.h drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Oct 19, 2022
-
-
openeuler-ci-bot authored
Merge Pull Request from: @babyihc This PR is to add ACS quirk for BCM57414 and BCM5750x NICs Kernel Issue: https://gitee.com/openeuler/kernel/issues/I5V2IE Upstream patchs: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/quirks.c?id=db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/quirks.c?id=afd306a65cedb9589564bdb23a0c368abc4215fd Link:https://gitee.com/openeuler/kernel/pulls/159 Reviewed-by:
Laibin Qiu <qiulaibin@huawei.com> Reviewed-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
openeuler-ci-bot authored
Merge Pull Request from: @babyihc This PR is cherry-pick from upstream "net: bonding: Add support for IPV6 ns/na to balance-alb/balance-tlb mode" Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0da8aa00bfcfeb3f4e6537dd8e2001e0727ba549 Link:https://gitee.com/openeuler/kernel/pulls/137 Reviewed-by:
Laibin Qiu <qiulaibin@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
Eric Dumazet authored
mainline inclusion from mainline-v6.1-rc1 commit ec7eede369fe5b0d085ac51fdbb95184f87bfc6c category: bugfix bugzilla: 187823, https://gitee.com/src-openeuler/kernel/issues/I5VZ0N CVE: CVE-2022-3521 -------------------------------- syzbot found that kcm_tx_work() could crash [1] in: /* Primarily for SOCK_SEQPACKET sockets */ if (likely(sk->sk_socket) && test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) { <<*>> clear_bit(SOCK_NOSPACE, &sk->sk_socket->flags); sk->sk_write_space(sk); } I think the reason is that another thread might concurrently run in kcm_release() and call sock_orphan(sk) while sk is not locked. kcm_tx_work() find sk->sk_socket being NULL. [1] BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:86 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in kcm_tx_work+0xff/0x160 net/kcm/kcmsock.c:742 Write of size 8 at addr 0000000000000008 by task kworker/u4:3/53 CPU: 0 PID: 53 Comm: kworker/u4:3 Not tainted 5.19.0-rc3-next-20220621-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: kkcmd kcm_tx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 instrument_atomic_write include/linux/instrumented.h:86 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] kcm_tx_work+0xff/0x160 net/kcm/kcmsock.c:742 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 </TASK> Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Tom Herbert <tom@herbertland.com> Link: https://lore.kernel.org/r/20221012133412.519394-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Baisong Zhong <zhongbaisong@huawei.com> Reviewed-by:
Liu Jian <liujian56@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Sun Shouxin authored
mainline inclusion from mainline-v5.4 commit 0da8aa00bfcfeb3f4e6537dd8e2001e0727ba549 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5UY5E CVE: NA -------------------------------- Since ipv6 neighbor solicitation and advertisement messages isn't handled gracefully in bond6 driver, we can see packet drop due to inconsistency between mac address in the option message and source MAC . Another examples is ipv6 neighbor solicitation and advertisement messages from VM via tap attached to host bridge, the src mac might be changed through balance-alb mode, but it is not synced with Link-layer address in the option message. The patch implements bond6's tx handle for ipv6 neighbor solicitation and advertisement messages. Suggested-by:
Hu Yadi <huyd12@chinatelecom.cn> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
Sun Shouxin <sunshouxin@chinatelecom.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sun Shouxin <sunshouxin@chinatelecom.cn>
-
- Oct 18, 2022
-
-
openeuler-ci-bot authored
Merge Pull Request from: @babyihc This PR is to fix nvme disk names not unique for the lifetime of the subsystem. Kernel issuse: https://gitee.com/openeuler/kernel/issues/I5986O Link:https://gitee.com/openeuler/kernel/pulls/139 Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com>
-
Hyunwoo Kim authored
mainline inclusion from mainline-v6.0-rc1 commit 5610bcfe8693c02e2e4c8b31427f1bdbdecc839c category: bugfix bugzilla: 187798, https://gitee.com/src-openeuler/kernel/issues/I5U1NZ CVE: CVE-2022-41849 -------------------------------- A race condition may occur if the user physically removes the USB device while calling open() for this device node. This is a race condition between the ufx_ops_open() function and the ufx_usb_disconnect() function, which may eventually result in UAF. So, add a mutex to the ufx_ops_open() and ufx_usb_disconnect() functions to avoid race contidion of krefs. Signed-off-by:
Hyunwoo Kim <imv4bel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
ChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Keith Busch authored
mainline inclusion from mainline-v5.9 commit 192f6c29 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5986O CVE: NA ---------------------------------- If the driver has to unbind from the controller for an early failure before the subsystem has been set up, there won't be a subsystem holding the controller's instance, so the controller needs to free its own instance in this case. Fixes: 733e4b69 ("nvme: Assign subsys instance from first ctrl") Signed-off-by:
Keith Busch <kbusch@kernel.org> Reviewed-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-
Keith Busch authored
mainline inclusion from mainline-v5.4 commit 733e4b69 category: bugfix bugzilla:https://gitee.com/openeuler/kernel/issues/I5986O CVE: NA -------------------------------- The namespace disk names must be unique for the lifetime of the subsystem. This was accomplished by using their parent subsystems' instances which were allocated independently from the controllers connected to that subsystem. This allowed name prefixes assigned to namespaces to match a controller from an unrelated subsystem, and has created confusion among users examining device nodes. Ensure a namespace's subsystem instance never clashes with a controller instance of another subsystem by transferring the instance ownership to the parent subsystem from the first controller discovered in that subsystem. Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Signed-off-by:
Keith Busch <kbusch@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Minwoo Im <minwoo.im@samsung.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-
Carlos Llamas authored
mainline inclusion from mainline-v6.0-rc4 commit a0e44c64b6061dda7e00b7c458e4523e2331b739 category: bugfix bugzilla: 187805, https://gitee.com/src-openeuler/kernel/issues/I5U713 CVE: CVE-2022-20421 -------------------------------- A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Acked-by:
Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by:
Carlos Llamas <cmllamas@google.com> Cc: stable <stable@kernel.org> # 4.14+ Link: https://lore.kernel.org/r/20220801182511.3371447-1-cmllamas@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ren Zhijie <renzhijie2@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
haibinzhang (张海斌) authored
stable inclusion from stable-v4.19.256 commit b51881b1da57fe9877125dfdd0aac5172958fcfd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5U71M CVE: CVE-2022-20422 --------------------------- [ Upstream commit af483947d472eccb79e42059276c4deed76f99a6 ] emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. Co-developed-by:
hewenliang <hewenliang4@huawei.com> Signed-off-by:
hewenliang <hewenliang4@huawei.com> Signed-off-by:
Haibin Zhang <haibinzhang@tencent.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220128090324.2727688-1-hewenliang4@huawei.com Link: https://lore.kernel.org/r/9A004C03-250B-46C5-BF39-782D7551B00E@tencent.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Reviewed-by:
Zhang Jianhua <chris.zjh@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Oct 17, 2022
-
-
Qian Cai authored
mainline inclusion from mainline-v5.6-rc1 commit 4a55c0474a92d5c418bcbbe122368de0910aeac2q category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5T5DD CVE: NA -------------------------------- It is not that hard to trigger lockdep splats by calling printk from under zone->lock. Most of them are false positives caused by lock chains introduced early in the boot process and they do not cause any real problems (although most of the early boot lock dependencies could happen after boot as well). There are some console drivers which do allocate from the printk context as well and those should be fixed. In any case, false positives are not that trivial to workaround and it is far from optimal to lose lockdep functionality for something that is a non-issue. So change has_unmovable_pages() so that it no longer calls dump_page() itself - instead it returns a "struct page *" of the unmovable page back to the caller so that in the case of a has_unmovable_pages() failure, the caller can call dump_page() after releasing zone->lock. Also, make dump_page() is able to report a CMA page as well, so the reason string from has_unmovable_pages() can be removed. Even though has_unmovable_pages doesn't hold any reference to the returned page this should be reasonably safe for the purpose of reporting the page (dump_page) because it cannot be hotremoved in the context of memory unplug. The state of the page might change but that is the case even with the existing code as zone->lock only plays role for free pages. While at it, remove a similar but unnecessary debug-only printk() as well. A sample of one of those lockdep splats is, WARNING: possible circular locking dependency detected ------------------------------------------------------ test.sh/8653 is trying to acquire lock: ffffffff865a4460 (console_owner){-.-.}, at: console_unlock+0x207/0x750 but task is already holding lock: ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at: __offline_isolated_pages+0x179/0x3e0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&(&zone->lock)->rlock){-.-.}: __lock_acquire+0x5b3/0xb40 lock_acquire+0x126/0x280 _raw_spin_lock+0x2f/0x40 rmqueue_bulk.constprop.21+0xb6/0x1160 get_page_from_freelist+0x898/0x22c0 __alloc_pages_nodemask+0x2f3/0x1cd0 alloc_pages_current+0x9c/0x110 allocate_slab+0x4c6/0x19c0 new_slab+0x46/0x70 ___slab_alloc+0x58b/0x960 __slab_alloc+0x43/0x70 __kmalloc+0x3ad/0x4b0 __tty_buffer_request_room+0x100/0x250 tty_insert_flip_string_fixed_flag+0x67/0x110 pty_write+0xa2/0xf0 n_tty_write+0x36b/0x7b0 tty_write+0x284/0x4c0 __vfs_write+0x50/0xa0 vfs_write+0x105/0x290 redirected_tty_write+0x6a/0xc0 do_iter_write+0x248/0x2a0 vfs_writev+0x106/0x1e0 do_writev+0xd4/0x180 __x64_sys_writev+0x45/0x50 do_syscall_64+0xcc/0x76c entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #2 (&(&port->lock)->rlock){-.-.}: __lock_acquire+0x5b3/0xb40 lock_acquire+0x126/0x280 _raw_spin_lock_irqsave+0x3a/0x50 tty_port_tty_get+0x20/0x60 tty_port_default_wakeup+0xf/0x30 tty_port_tty_wakeup+0x39/0x40 uart_write_wakeup+0x2a/0x40 serial8250_tx_chars+0x22e/0x440 serial8250_handle_irq.part.8+0x14a/0x170 serial8250_default_handle_irq+0x5c/0x90 serial8250_interrupt+0xa6/0x130 __handle_irq_event_percpu+0x78/0x4f0 handle_irq_event_percpu+0x70/0x100 handle_irq_event+0x5a/0x8b handle_edge_irq+0x117/0x370 do_IRQ+0x9e/0x1e0 ret_from_intr+0x0/0x2a cpuidle_enter_state+0x156/0x8e0 cpuidle_enter+0x41/0x70 call_cpuidle+0x5e/0x90 do_idle+0x333/0x370 cpu_startup_entry+0x1d/0x1f start_secondary+0x290/0x330 secondary_startup_64+0xb6/0xc0 -> #1 (&port_lock_key){-.-.}: __lock_acquire+0x5b3/0xb40 lock_acquire+0x126/0x280 _raw_spin_lock_irqsave+0x3a/0x50 serial8250_console_write+0x3e4/0x450 univ8250_console_write+0x4b/0x60 console_unlock+0x501/0x750 vprintk_emit+0x10d/0x340 vprintk_default+0x1f/0x30 vprintk_func+0x44/0xd4 printk+0x9f/0xc5 -> #0 (console_owner){-.-.}: check_prev_add+0x107/0xea0 validate_chain+0x8fc/0x1200 __lock_acquire+0x5b3/0xb40 lock_acquire+0x126/0x280 console_unlock+0x269/0x750 vprintk_emit+0x10d/0x340 vprintk_default+0x1f/0x30 vprintk_func+0x44/0xd4 printk+0x9f/0xc5 __offline_isolated_pages.cold.52+0x2f/0x30a offline_isolated_pages_cb+0x17/0x30 walk_system_ram_range+0xda/0x160 __offline_pages+0x79c/0xa10 offline_pages+0x11/0x20 memory_subsys_offline+0x7e/0xc0 device_offline+0xd5/0x110 state_store+0xc6/0xe0 dev_attr_store+0x3f/0x60 sysfs_kf_write+0x89/0xb0 kernfs_fop_write+0x188/0x240 __vfs_write+0x50/0xa0 vfs_write+0x105/0x290 ksys_write+0xc6/0x160 __x64_sys_write+0x43/0x50 do_syscall_64+0xcc/0x76c entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Chain exists of: console_owner --> &(&port->lock)->rlock --> &(&zone->lock)->rlock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&zone->lock)->rlock); lock(&(&port->lock)->rlock); lock(&(&zone->lock)->rlock); lock(console_owner); *** DEADLOCK *** 9 locks held by test.sh/8653: #0: ffff88839ba7d408 (sb_writers#4){.+.+}, at: vfs_write+0x25f/0x290 #1: ffff888277618880 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x240 #2: ffff8898131fc218 (kn->count#115){.+.+}, at: kernfs_fop_write+0x138/0x240 #3: ffffffff86962a80 (device_hotplug_lock){+.+.}, at: lock_device_hotplug_sysfs+0x16/0x50 #4: ffff8884374f4990 (&dev->mutex){....}, at: device_offline+0x70/0x110 #5: ffffffff86515250 (cpu_hotplug_lock.rw_sem){++++}, at: __offline_pages+0xbf/0xa10 #6: ffffffff867405f0 (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x87/0x2f0 #7: ffff88883fff3c58 (&(&zone->lock)->rlock){-.-.}, at: __offline_isolated_pages+0x179/0x3e0 #8: ffffffff865a4920 (console_lock){+.+.}, at: vprintk_emit+0x100/0x340 stack backtrace: Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10, BIOS U34 05/21/2019 Call Trace: dump_stack+0x86/0xca print_circular_bug.cold.31+0x243/0x26e check_noncircular+0x29e/0x2e0 check_prev_add+0x107/0xea0 validate_chain+0x8fc/0x1200 __lock_acquire+0x5b3/0xb40 lock_acquire+0x126/0x280 console_unlock+0x269/0x750 vprintk_emit+0x10d/0x340 vprintk_default+0x1f/0x30 vprintk_func+0x44/0xd4 printk+0x9f/0xc5 __offline_isolated_pages.cold.52+0x2f/0x30a offline_isolated_pages_cb+0x17/0x30 walk_system_ram_range+0xda/0x160 __offline_pages+0x79c/0xa10 offline_pages+0x11/0x20 memory_subsys_offline+0x7e/0xc0 device_offline+0xd5/0x110 state_store+0xc6/0xe0 dev_attr_store+0x3f/0x60 sysfs_kf_write+0x89/0xb0 kernfs_fop_write+0x188/0x240 __vfs_write+0x50/0xa0 vfs_write+0x105/0x290 ksys_write+0xc6/0x160 __x64_sys_write+0x43/0x50 do_syscall_64+0xcc/0x76c entry_SYSCALL_64_after_hwframe+0x49/0xbe Link: http://lkml.kernel.org/r/20200117181200.20299-1-cai@lca.pw Signed-off-by:
Qian Cai <cai@lca.pw> Reviewed-by:
David Hildenbrand <david@redhat.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Conflicts: mm/debug.c mm/page_alloc. mm/page_isolation.c mm/page-isolation.h Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Xia Fukun authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5UPB0 CVE: NA ------------------------------------------------------------ After CONFIG_SMP is disabled during kernel compilation, CONFIG_QOS_SCHED is not disabled. As a result, the following error occurs: kernel/sched/fair.c: In function ‘check_qos_cfs_rq’: kernel/sched/fair.c:7324:4: error: implicit declaration of function ‘sched_idle_cpu’; did you mean ‘sched_idle_rq’? [-Werror=implicit-function-declaration] 7324 | !sched_idle_cpu(smp_processor_id()) && | ^~~~~~~~~~~~~~ ./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’ 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ CC mm/highmem.o kernel/sched/fair.c: In function ‘pick_next_task_fair’: kernel/sched/fair.c:7599:43: error: ‘struct rq’ has no member named ‘online’ 7599 | if (cfs_rq->...
-
- Oct 14, 2022
-
-
Ma Wupeng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP CVE: CVE-2022-42703 -------------------------------- In order to fix CVE-2022-42703, degree in struct anon_vma is splited into two variables(num_children, num_active_vmas) and this will lead to broken kabi. Since struct anon_vma is only used by mm module and referenced by other struct as pointers. So we can ignore this kabi change warning. For variable degree in struct anon_vma, previous patch has already delete this but this will lead to kabi change. Add it back at the same position. For variables(num_children, num_active_vmas), put them between macro __GENKSYMS__. Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Jann Horn authored
stable inclusion from stable-v4.19.257 commit 6dbfc25d68d922736381988d64156a649ccf7bf1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP CVE: CVE-2022-42703 -------------------------------- commit 2555283eb40df89945557273121e9393ef9b542b upstream. anon_vma->degree tracks the combined number of child anon_vmas and VMAs that use the anon_vma as their ->anon_vma. anon_vma_clone() then assumes that for any anon_vma attached to src->anon_vma_chain other than src->anon_vma, it is impossible for it to be a leaf node of the VMA tree, meaning that for such VMAs ->degree is elevated by 1 because of a child anon_vma, meaning that if ->degree equals 1 there are no VMAs that use the anon_vma as their ->anon_vma. This assumption is wrong because the ->degree optimization leads to leaf nodes being abandoned on anon_vma_clone() - an existing anon_vma is reused and no new parent-child relationship is created. So it is possible to reuse an anon_vma for one VMA while it is still tied to another VMA. This is an issue because is_mergeable_anon_vma() and its callers assume that if two VMAs have the same ->anon_vma, the list of anon_vmas attached to the VMAs is guaranteed to be the same. When this assumption is violated, vma_merge() can merge pages into a VMA that is not attached to the corresponding anon_vma, leading to dangling page->mapping pointers that will be dereferenced during rmap walks. Fix it by separately tracking the number of child anon_vmas and the number of VMAs using the anon_vma as their ->anon_vma. Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy") Cc: stable@kernel.org Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hyunwoo Kim authored
mainline inclusion from mainline master commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5U1PE CVE: CVE-2022-41850 -------------------------------- roccat_report_event() is responsible for registering roccat-related reports in struct roccat_device. int roccat_report_event(int minor, u8 const *data) { struct roccat_device *device; struct roccat_reader *reader; struct roccat_report *report; uint8_t *new_value; device = devices[minor]; new_value = kmemdup(data, device->report_size, GFP_ATOMIC); if (!new_value) return -ENOMEM; report = &device->cbuf[device->cbuf_end]; /* passing NULL is safe */ kfree(report->value); ... The registered report is stored in the struct roccat_device member "struct roccat_report cbuf[ROCCAT_CBUF_SIZE];". If more reports are received than the "ROCCAT_CBUF_SIZE" value, kfree() the saved report from cbuf[0] and allocates a new reprot. Since there is no lock when this kfree() is performed, kfree() can be performed even while reading the saved report. static ssize_t roccat_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) { struct roccat_reader *reader = file->private_data; struct roccat_device *device = reader->device; struct roccat_report *report; ssize_t retval = 0, len; DECLARE_WAITQUEUE(wait, current); mutex_lock(&device->cbuf_lock); ... report = &device->cbuf[reader->cbuf_start]; /* * If report is larger than requested amount of data, rest of report * is lost! */ len = device->report_size > count ? count : device->report_size; if (copy_to_user(buffer, report->value, len)) { retval = -EFAULT; goto exit_unlock; } ... The roccat_read() function receives the device->cbuf report and delivers it to the user through copy_to_user(). If the N+ROCCAT_CBUF_SIZE th report is received while copying of the Nth report->value is in progress, the pointer that copy_to_user() is working on is kfree()ed and UAF read may occur. (race condition) Since the device node of this driver does not set separate permissions, this is not a security vulnerability, but because it is used for requesting screen display of profile or dpi settings, a user using the roccat device can apply udev to this device node or There is a possibility to use it by giving. Signed-off-by:
Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Cai Xinchen <caixinchen1@huawei.com> Reviewed-by:
Ruiqi Gong <gongruiqi1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Oct 12, 2022
-
-
Pavan Chebbi authored
mainline inclusion from master commit afd306a65cedb9589564bdb23a0c368abc4215fd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5V2IE CVE: NA ------------------------------------------- The Broadcom BCM5750x NICs may be multi-function devices. They do not advertise ACS capability. Peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for these devices so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. Link: https://lore.kernel.org/r/1654796507-28610-1-git-send-email-michael.chan@broadcom.com Signed-off-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-
Sriharsha Basavapatna authored
mainline inclusion from mainline-v5.10 commit db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5V2IE CVE: NA ------------------------------------------- The Broadcom BCM57414 NIC may be a multi-function device. While it does not advertise an ACS capability, peer-to-peer transactions are not possible between the individual functions, so it is safe to treat them as fully isolated. Add an ACS quirk for this device so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. [bhelgaas: commit log] Link: https://lore.kernel.org/r/1621645997-16251-1-git-send-email-michael.chan@broadcom.com Signed-off-by:
Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Xibo.Wang <wangxb12@chinatelecom.cn>
-