- 07 8月, 2023 5 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Yi Yang <yiyang13@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FA2B7TOM3KI377VPITPMUXX6FWMNJ2NK/ https://gitee.com/openeuler/kernel/issues/I7PBYJ Link:https://gitee.com/openeuler/kernel/pulls/1663 Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Yi Yang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PBYJ -------------------------------- There is memleak in alloc_pid: ------------------------------ unreferenced object 0xffff88810c181940 (size 224): comm "sshd", pid 8191, jiffies 4294946950 (age 524.570s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N.. ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff ....kkkk........ backtrace: [<ffffffff814774e6>] kmem_cache_alloc+0x5c6/0x9b0 [<ffffffff81177342>] alloc_pid+0x72/0x570 [<ffffffff81140ac4>] copy_process+0x1374/0x2470 [<ffffffff81141d77>] kernel_clone+0xb7/0x900 [<ffffffff81142645>] __se_sys_clone+0x85/0xb0 [<ffffffff8114269b>] __x64_sys_clone+0x2b/0x30 [<ffffffff83965a72>] do_syscall_64+0x32/0x80 [<ffffffff83a00085>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 The pid memleak is triggered by the following race: task[sshd] task[bash] ----------------------- ----------------------- do_exit(); disassociate_ctty(); spin_lock_irq(¤t->sighand->siglock); put_pid(current->signal->tty_old_pgrp); current->signal->tty_old_pgrp = NULL; tty = tty_kref_get(current->signal->tty); //tty is not NULL spin_unlock_irq(¤t->sighand->siglock); tty_vhangup(); tty_lock(tty); ... tty_signal_session_leader(); spin_lock_irq(&p->sighand->siglock); ... p->signal->tty_old_pgrp = get_pid(tty->pgrp); // tty_old_pgrp reassign spin_unlock_irq(&p->sighand->siglock); ... tty_unlock(tty); if (tty) { tty_lock(tty); ... put_pid(tty->pgrp); tty->pgrp = NULL;// It's too late ... tty_unlock(tty); } in task[bash], tty_old_pgrp is released by disassociate_ctty(), then it's reassigned by tty_signal_session_leader() in task[sshd], cause memleak. fix the memleak by add put_pid() in disassociate_ctty() after tty_old_pgrp is reassigned. Fixes: c8bcd9c5 ("tty: Fix ->session locking") Signed-off-by: NYi Yang <yiyang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PN6CJX7CQ6YCEZFFWSQPDTGBGIIF7PGE/ Backport can/raw receiver memory leak fix commits. Eric Dumazet (1): can: raw: fix lockdep issue in raw_release() Ziyang Xuan (1): can: raw: fix receiver memory leak -- 2.25.1 https://gitee.com/openeuler/kernel/issues/I7PM10 Link:https://gitee.com/openeuler/kernel/pulls/1629 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Dong Chenchen <dongchenchen2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7EQSQN64OKQD5VUXFEKT6K4XAFZ52LBI/ https://gitee.com/openeuler/kernel/issues/I7R1N4 Link:https://gitee.com/openeuler/kernel/pulls/1655 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 YueHaibing 提交于
mainline inclusion from mainline-v6.5-rc1 commit 55c3b96074f3f9b0aee19bf93cd71af7516582bb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7R1N4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=55c3b96074f3f9b0aee19bf93cd71af7516582bb --------------------------- BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to bcm_proc_show() may read the freed bcm_op. Fixes: ffd980f9 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: NYueHaibing <yuehaibing@huawei.com> Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net> Acked-by: NOliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com Cc: stable@vger.kernel.org Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
-
- 03 8月, 2023 6 次提交
-
-
由 Eric Dumazet 提交于
mainline inclusion from mainline-v6.5-rc4 commit 11c9027c983e9e4b408ee5613b6504d24ebd85be category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PM10 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11c9027c983e9e4b408ee5613b6504d24ebd85be --------------------------- syzbot complained about a lockdep issue [1] Since raw_bind() and raw_setsockopt() first get RTNL before locking the socket, we must adopt the same order in raw_release() [1] WARNING: possible circular locking dependency detected 6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0 Not tainted ------------------------------------------------------ syz-executor.0/14110 is trying to acquire lock: ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1708 [inline] ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: raw_bind+0xb1/0xab0 net/can/raw.c:435 but task is already holding lock: ffffffff8e3df368 (rtnl_mutex){+.+.}-{3:3}, at: raw_bind+0xa7/0xab0 net/can/raw.c:434 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x181/0x1340 kernel/locking/mutex.c:747 raw_release+0x1c6/0x9b0 net/can/raw.c:391 __sock_release+0xcd/0x290 net/socket.c:654 sock_close+0x1c/0x20 net/socket.c:1386 __fput+0x3fd/0xac0 fs/file_table.c:384 task_work_run+0x14d/0x240 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:297 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (sk_lock-AF_CAN){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144 lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492 lock_sock include/net/sock.h:1708 [inline] raw_bind+0xb1/0xab0 net/can/raw.c:435 __sys_bind+0x1ec/0x220 net/socket.c:1792 __do_sys_bind net/socket.c:1803 [inline] __se_sys_bind net/socket.c:1801 [inline] __x64_sys_bind+0x72/0xb0 net/socket.c:1801 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(sk_lock-AF_CAN); lock(rtnl_mutex); lock(sk_lock-AF_CAN); *** DEADLOCK *** 1 lock held by syz-executor.0/14110: stack backtrace: CPU: 0 PID: 14110 Comm: syz-executor.0 Not tainted 6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 check_noncircular+0x311/0x3f0 kernel/locking/lockdep.c:2195 check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144 lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492 lock_sock include/net/sock.h:1708 [inline] raw_bind+0xb1/0xab0 net/can/raw.c:435 __sys_bind+0x1ec/0x220 net/socket.c:1792 __do_sys_bind net/socket.c:1803 [inline] __se_sys_bind net/socket.c:1801 [inline] __x64_sys_bind+0x72/0xb0 net/socket.c:1801 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd89007cb29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd890d2a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007fd89019bf80 RCX: 00007fd89007cb29 RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fd8900c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd89019bf80 R15: 00007ffebf8124f8 </TASK> Fixes: ee8b94c8510c ("can: raw: fix receiver memory leak") Reported-by: Nsyzbot <syzkaller@googlegroups.com> Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Ziyang Xuan <william.xuanziyang@huawei.com> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Cc: stable@vger.kernel.org Cc: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/all/20230720114438.172434-1-edumazet@google.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Ziyang Xuan 提交于
mainline inclusion from mainline-v6.5-rc3 commit ee8b94c8510ce64afe0b87ef548d23e00915fb10 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PM10 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee8b94c8510ce64afe0b87ef548d23e00915fb10 --------------------------- Got kmemleak errors with the following ltp can_filter testcase: for ((i=1; i<=100; i++)) do ./can_filter & sleep 0.1 done ============================================================== [<00000000db4a4943>] can_rx_register+0x147/0x360 [can] [<00000000a289549d>] raw_setsockopt+0x5ef/0x853 [can_raw] [<000000006d3d9ebd>] __sys_setsockopt+0x173/0x2c0 [<00000000407dbfec>] __x64_sys_setsockopt+0x61/0x70 [<00000000fd468496>] do_syscall_64+0x33/0x40 [<00000000b7e47d51>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 It's a bug in the concurrent scenario of unregister_netdevice_many() and raw_release() as following: cpu0 cpu1 unregister_netdevice_many(can_dev) unlist_netdevice(can_dev) // dev_get_by_index() return NULL after this net_set_todo(can_dev) raw_release(can_socket) dev = dev_get_by_index(, ro->ifindex); // dev == NULL if (dev) { // receivers in dev_rcv_lists not free because dev is NULL raw_disable_allfilters(, dev, ); dev_put(dev); } ... ro->bound = 0; ... call_netdevice_notifiers(NETDEV_UNREGISTER, ) raw_notify(, NETDEV_UNREGISTER, ) if (ro->bound) // invalid because ro->bound has been set 0 raw_disable_allfilters(, dev, ); // receivers in dev_rcv_lists will never be freed Add a net_device pointer member in struct raw_sock to record bound can_dev, and use rtnl_lock to serialize raw_socket members between raw_bind(), raw_release(), raw_setsockopt() and raw_notify(). Use ro->dev to decide whether to free receivers in dev_rcv_lists. Fixes: 8d0caedb ("can: bcm/raw/isotp: use per module netdevice notifier") Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net> Acked-by: NOliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Link: https://lore.kernel.org/all/20230711011737.1969582-1-william.xuanziyang@huawei.com Cc: stable@vger.kernel.org Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Conflicts: net/can/raw.c Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Lei Chen <lei.chen@smartx.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YBB4FWVDSAGSXOH4VTUKE6MMDOJWYADW/ v2: 1. using full commit id instead of abbrevation 2. fix wrong mainline tag Sean Christopherson (1): KVM: Don't set Accessed/Dirty bits for ZERO_PAGE Zhuang Yanying (1): KVM: fix overflow of zero page refcount with ksm running -- 2.34.1 https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue Link:https://gitee.com/openeuler/kernel/pulls/1625 Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/H6ZQ55XGUXRWXUV5UOR5EIVMPTK4H3Z2/ Backport CVE-2023-3863 fix commits. Aditya Pakki (1): nfc: Fix to check for kmemdup failure Krzysztof Kozlowski (2): nfc: llcp: nullify llcp_sock->dev on connect() error paths nfc: llcp: simplify llcp_sock_connect() error paths Lin Ma (1): net: nfc: Fix use-after-free caused by nfc_llcp_find_local -- 2.25.1 https://gitee.com/src-openeuler/kernel/issues/I7NLJR Link:https://gitee.com/openeuler/kernel/pulls/1595 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Sean Christopherson 提交于
mainline inclusion from mainline-v6.0-rc1 commit a1040b0d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue CVE: NA -------------------------------- Don't set Accessed/Dirty bits for a struct page with PG_reserved set, i.e. don't set A/D bits for the ZERO_PAGE. The ZERO_PAGE (or pages depending on the architecture) should obviously never be written, and similarly there's no point in marking it accessed as the page will never be swapped out or reclaimed. The comment in page-flags.h is quite clear that PG_reserved pages should be managed only by their owner, and strictly following that mandate also simplifies KVM's logic. Fixes: 7df003c8 ("KVM: fix overflow of zero page refcount with ksm running") Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20220429010416.2788472-4-seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NLei Chen <lei.chen@smartx.com>
-
由 Zhuang Yanying 提交于
mainline inclusion from mainline-v5.6-rc1 commit 7df003c8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7PQPE?from=project-issue CVE: NA -------------------------------- We are testing Virtual Machine with KSM on v5.4-rc2 kernel, and found the zero_page refcount overflow. The cause of refcount overflow is increased in try_async_pf (get_user_page) without being decreased in mmu_set_spte() while handling ept violation. In kvm_release_pfn_clean(), only unreserved page will call put_page. However, zero page is reserved. So, as well as creating and destroy vm, the refcount of zero page will continue to increase until it overflows. step1: echo 10000 > /sys/kernel/pages_to_scan/pages_to_scan echo 1 > /sys/kernel/pages_to_scan/run echo 1 > /sys/kernel/pages_to_scan/use_zero_pages step2: just create several normal qemu kvm vms. And destroy it after 10s. Repeat this action all the time. After a long period of time, all domains hang because of the refcount of zero page overflow. Qemu print error log as follow: … error: kvm run failed Bad address EAX=00006cdc EBX=00000008 ECX=80202001 EDX=078bfbfd ESI=ffffffff EDI=00000000 EBP=00000008 ESP=00006cc4 EIP=000efd75 EFL=00010002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000f7070 00000037 IDT= 000f70ae 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 Code=00 01 00 00 00 e9 e8 00 00 00 c7 05 4c 55 0f 00 01 00 00 00 <8b> 35 00 00 01 00 8b 3d 04 00 01 00 b8 d8 d3 00 00 c1 e0 08 0c ea a3 00 00 01 00 c7 05 04 … Meanwhile, a kernel warning is departed. [40914.836375] WARNING: CPU: 3 PID: 82067 at ./include/linux/mm.h:987 try_get_page+0x1f/0x30 [40914.836412] CPU: 3 PID: 82067 Comm: CPU 0/KVM Kdump: loaded Tainted: G OE 5.2.0-rc2 #5 [40914.836415] RIP: 0010:try_get_page+0x1f/0x30 [40914.836417] Code: 40 00 c3 0f 1f 84 00 00 00 00 00 48 8b 47 08 a8 01 75 11 8b 47 34 85 c0 7e 10 f0 ff 47 34 b8 01 00 00 00 c3 48 8d 78 ff eb e9 <0f> 0b 31 c0 c3 66 90 66 2e 0f 1f 84 00 0 0 00 00 00 48 8b 47 08 a8 [40914.836418] RSP: 0018:ffffb4144e523988 EFLAGS: 00010286 [40914.836419] RAX: 0000000080000000 RBX: 0000000000000326 RCX: 0000000000000000 [40914.836420] RDX: 0000000000000000 RSI: 00004ffdeba10000 RDI: ffffdf07093f6440 [40914.836421] RBP: ffffdf07093f6440 R08: 800000424fd91225 R09: 0000000000000000 [40914.836421] R10: ffff9eb41bfeebb8 R11: 0000000000000000 R12: ffffdf06bbd1e8a8 [40914.836422] R13: 0000000000000080 R14: 800000424fd91225 R15: ffffdf07093f6440 [40914.836423] FS: 00007fb60ffff700(0000) GS:ffff9eb4802c0000(0000) knlGS:0000000000000000 [40914.836425] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40914.836426] CR2: 0000000000000000 CR3: 0000002f220e6002 CR4: 00000000003626e0 [40914.836427] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [40914.836427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [40914.836428] Call Trace: [40914.836433] follow_page_pte+0x302/0x47b [40914.836437] __get_user_pages+0xf1/0x7d0 [40914.836441] ? irq_work_queue+0x9/0x70 [40914.836443] get_user_pages_unlocked+0x13f/0x1e0 [40914.836469] __gfn_to_pfn_memslot+0x10e/0x400 [kvm] [40914.836486] try_async_pf+0x87/0x240 [kvm] [40914.836503] tdp_page_fault+0x139/0x270 [kvm] [40914.836523] kvm_mmu_page_fault+0x76/0x5e0 [kvm] [40914.836588] vcpu_enter_guest+0xb45/0x1570 [kvm] [40914.836632] kvm_arch_vcpu_ioctl_run+0x35d/0x580 [kvm] [40914.836645] kvm_vcpu_ioctl+0x26e/0x5d0 [kvm] [40914.836650] do_vfs_ioctl+0xa9/0x620 [40914.836653] ksys_ioctl+0x60/0x90 [40914.836654] __x64_sys_ioctl+0x16/0x20 [40914.836658] do_syscall_64+0x5b/0x180 [40914.836664] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [40914.836666] RIP: 0033:0x7fb61cb6bfc7 Signed-off-by: NLinFeng <linfeng23@huawei.com> Signed-off-by: NZhuang Yanying <ann.zhuangyanying@huawei.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NLei Chen <lei.chen@smartx.com>
-
- 31 7月, 2023 4 次提交
-
-
由 Lin Ma 提交于
mainline inclusion from mainline-v6.5-rc1 commit 6709d4b7bc2e079241fdef15d1160581c5261c10 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6709d4b7bc2e079241fdef15d1160581c5261c10 --------------------------- This commit fixes several use-after-free that caused by function nfc_llcp_find_local(). For example, one UAF can happen when below buggy time window occurs. // nfc_genl_llc_get_params | // nfc_unregister_device | dev = nfc_get_device(idx); | device_lock(...) if (!dev) | dev->shutting_down = true; return -ENODEV; | device_unlock(...); | device_lock(...); | // nfc_llcp_unregister_device | nfc_llcp_find_local() nfc_llcp_find_local(...); | | local_cleanup() if (!local) { | rc = -ENODEV; | // nfc_llcp_local_put goto exit; | kref_put(.., local_release) } | | // local_release | list_del(&local->list) // nfc_genl_send_params | kfree() local->dev->idx !!!UAF!!! | | and the crash trace for the one of the discussed UAF like: BUG: KASAN: slab-use-after-free in nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045 Read of size 8 at addr ffff888105b0e410 by task 20114 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:319 [inline] print_report+0xcc/0x620 mm/kasan/report.c:430 kasan_report+0xb2/0xe0 mm/kasan/report.c:536 nfc_genl_send_params net/nfc/netlink.c:999 [inline] nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045 genl_family_rcv_msg_doit.isra.0+0x1ee/0x2e0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x503/0x7d0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x161/0x430 net/netlink/af_netlink.c:2548 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x644/0x900 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x934/0xe70 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b6/0x200 net/socket.c:747 ____sys_sendmsg+0x6e9/0x890 net/socket.c:2501 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555 __sys_sendmsg+0xf7/0x1d0 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f34640a2389 RSP: 002b:00007f3463415168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f34641c1f80 RCX: 00007f34640a2389 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000006 RBP: 00007f34640ed493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe38449ecf R14: 00007f3463415300 R15: 0000000000022000 </TASK> Allocated by task 20116: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x7f/0x90 mm/kasan/common.c:383 kmalloc include/linux/slab.h:580 [inline] kzalloc include/linux/slab.h:720 [inline] nfc_llcp_register_device+0x49/0xa40 net/nfc/llcp_core.c:1567 nfc_register_device+0x61/0x260 net/nfc/core.c:1124 nci_register_device+0x776/0xb20 net/nfc/nci/core.c:1257 virtual_ncidev_open+0x147/0x230 drivers/nfc/virtual_ncidev.c:148 misc_open+0x379/0x4a0 drivers/char/misc.c:165 chrdev_open+0x26c/0x780 fs/char_dev.c:414 do_dentry_open+0x6c4/0x12a0 fs/open.c:920 do_open fs/namei.c:3560 [inline] path_openat+0x24fe/0x37e0 fs/namei.c:3715 do_filp_open+0x1ba/0x410 fs/namei.c:3742 do_sys_openat2+0x171/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_openat fs/open.c:1388 [inline] __se_sys_openat fs/open.c:1383 [inline] __x64_sys_openat+0x143/0x200 fs/open.c:1383 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 20115: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x50 mm/kasan/generic.c:521 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free mm/kasan/common.c:200 [inline] __kasan_slab_free+0x10a/0x190 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:162 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook mm/slub.c:1807 [inline] slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x7a/0x190 mm/slub.c:3800 local_release net/nfc/llcp_core.c:174 [inline] kref_put include/linux/kref.h:65 [inline] nfc_llcp_local_put net/nfc/llcp_core.c:182 [inline] nfc_llcp_local_put net/nfc/llcp_core.c:177 [inline] nfc_llcp_unregister_device+0x206/0x290 net/nfc/llcp_core.c:1620 nfc_unregister_device+0x160/0x1d0 net/nfc/core.c:1179 virtual_ncidev_close+0x52/0xa0 drivers/nfc/virtual_ncidev.c:163 __fput+0x252/0xa20 fs/file_table.c:321 task_work_run+0x174/0x270 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x108/0x110 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x21/0x50 kernel/entry/common.c:297 do_syscall_64+0x4c/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdc Last potentially related work creation: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 __kasan_record_aux_stack+0x95/0xb0 mm/kasan/generic.c:491 kvfree_call_rcu+0x29/0xa80 kernel/rcu/tree.c:3328 drop_sysctl_table+0x3be/0x4e0 fs/proc/proc_sysctl.c:1735 unregister_sysctl_table.part.0+0x9c/0x190 fs/proc/proc_sysctl.c:1773 unregister_sysctl_table+0x24/0x30 fs/proc/proc_sysctl.c:1753 neigh_sysctl_unregister+0x5f/0x80 net/core/neighbour.c:3895 addrconf_notify+0x140/0x17b0 net/ipv6/addrconf.c:3684 notifier_call_chain+0xbe/0x210 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x150 net/core/dev.c:1937 call_netdevice_notifiers_extack net/core/dev.c:1975 [inline] call_netdevice_notifiers net/core/dev.c:1989 [inline] dev_change_name+0x3c3/0x870 net/core/dev.c:1211 dev_ifsioc+0x800/0xf70 net/core/dev_ioctl.c:376 dev_ioctl+0x3d9/0xf80 net/core/dev_ioctl.c:542 sock_do_ioctl+0x160/0x260 net/socket.c:1213 sock_ioctl+0x3f9/0x670 net/socket.c:1316 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19e/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc The buggy address belongs to the object at ffff888105b0e400 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff888105b0e400, ffff888105b0e800) The buggy address belongs to the physical page: head:ffffea000416c200 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffff8881000430c0 ffffea00044c7010 ffffea0004510e10 raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888105b0e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888105b0e380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888105b0e400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888105b0e480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888105b0e500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb In summary, this patch solves those use-after-free by 1. Re-implement the nfc_llcp_find_local(). The current version does not grab the reference when getting the local from the linked list. For example, the llcp_sock_bind() gets the reference like below: // llcp_sock_bind() local = nfc_llcp_find_local(dev); // A ..... \ | raceable ..... / llcp_sock->local = nfc_llcp_local_get(local); // B There is an apparent race window that one can drop the reference and free the local object fetched in (A) before (B) gets the reference. 2. Some callers of the nfc_llcp_find_local() do not grab the reference at all. For example, the nfc_genl_llc_{{get/set}_params/sdreq} functions. We add the nfc_llcp_local_put() for them. Moreover, we add the necessary error handling function to put the reference. 3. Add the nfc_llcp_remove_local() helper. The local object is removed from the linked list in local_release() when all reference is gone. This patch removes it when nfc_llcp_unregister_device() is called. Therefore, every caller of nfc_llcp_find_local() will get a reference even when the nfc_llcp_unregister_device() is called. This promises no use-after-free for the local object is ever possible. Fixes: 52feb444 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support") Fixes: c7aa1225 ("NFC: Take a reference on the LLCP local pointer when creating a socket") Signed-off-by: NLin Ma <linma@zju.edu.cn> Reviewed-by: NSimon Horman <simon.horman@corigine.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Krzysztof Kozlowski 提交于
mainline inclusion from mainline-v5.18-rc1 commit ec10fd15 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec10fd154d934cc4195da3cbd017a12817b41d51 --------------------------- The llcp_sock_connect() error paths were using a mixed way of central exit (goto) and cleanup Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Krzysztof Kozlowski 提交于
mainline inclusion from mainline-v5.18-rc1 commit 13a3585b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a3585b264bfeba018941a713b8d7fc9b8221a2 --------------------------- Nullify the llcp_sock->dev on llcp_sock_connect() error paths, symmetrically to the code llcp_sock_bind(). The non-NULL value of llcp_sock->dev is used in a few places to check whether the socket is still valid. There was no particular issue observed with missing NULL assignment in connect() error path, however a similar case - in the bind() error path - was triggereable. That one was fixed in commit 4ac06a1e ("nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect"), so the change here seems logical as well. Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
由 Aditya Pakki 提交于
mainline inclusion from mainline-v5.1-rc3 commit d7737d42 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLJR CVE: CVE-2023-3863 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7737d4257459ca8921ff911c88937be1a11ea9d --------------------------- In case of kmemdup failure while setting the service name the patch returns -ENOMEM upstream for processing. Signed-off-by: NAditya Pakki <pakki001@umn.edu> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Conflicts: net/nfc/llcp_sock.c Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
-
- 29 7月, 2023 11 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @liuyonglong86 This patch set fix wrong head when modify the tx feature when sending packets problem and modify the driver version. Link:https://gitee.com/openeuler/kernel/pulls/1571 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @liuyonglong86 This patch set fix some bugs found on hns3 drivers and modify the driver version. Link:https://gitee.com/openeuler/kernel/pulls/1570 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: other bugzilla: https://gitee.com/openeuler/kernel/issues/I7OSIE CVE: NA ---------------------------- Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OSIE CVE: NA ---------------------------- When modify the tx feature, the hns driver will modify the maybe_stop_tx() and fill_desc() functions, if the modify happens during packet sending, will cause the hardware and software pointers do not match, and the port can not work anymore. This patch deletes the maybe_stop_tx() and fill_desc() functions modification when setting tx feature, and use the skb_is_gro() to determine use tso functions or non-tso functions when packets sending. Fixes: 38f616da ("net:hns: Add support of ethtool TSO set option for Hip06 in HNS") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OS1B CVE: NA ---------------------------- Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Jian Shen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OS1B CVE: NA ---------------------------- Currently, the driver knocks the ring doorbell before updating the ring->last_to_use in tx flow. if the hardware transmiting packet and napi poll scheduling are fast enough, it may get the old ring->last_to_use in drivers' napi poll. In this case, the driver will think the tx is not completed, and return directly without clear the flag __QUEUE_STATE_STACK_XOFF, which may cause tx timeout. Fixes: 62ef41eb ("net: hns3: optimize the tx clean process") Signed-off-by: NJian Shen <shenjian15@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ORRB CVE: NA ---------------------------- Currently, the HNS3 driver reports the rss hash type of each packet based on the rss hash tuples set. It always reports PKT_HASH_TYPE_L4, without checking the type of current packet. It's incorrect. Fixes it by reporting it base on the packet type. Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb") Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OQCS CVE: NA ---------------------------- In hclgevf_mbx_handler() and hclgevf_get_mbx_resp() functions, there is a typical store-store and load-load scenario between received_resp and additional_info. This patch adds barrier to fix the problem. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Jie Wang 提交于
mainline inclusion from mainline-v5.16-rc6 commit 27cbf64a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OQ7U CVE: NA ---------------------------- Currently, the hns3_remove function firstly uninstall client instance, and then uninstall acceletion engine device. The netdevice is freed in client instance uninstall process, but acceletion engine device uninstall process still use it to trace runtime information. This causes a use after free problem. So fixes it by check the instance register state to avoid use after free. Fixes: d8355240 ("net: hns3: add trace event support for PF/VF mailbox") Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7OPD3 CVE: NA ---------------------------- The variable reset_fail_cnt has moved into the struct rst_stats, but in hclge_reset_end_it(), still using the old reset_fail_cnt, so when reset fail, the reset_fail_cnt is always 0, and will not call nic_call_event() to notify who cares about this event. This patch use the correct variable rst_stats.reset_fail_cnt to fix the problem. Fixes: bc70c292 ("net: hns3: add some DFX info for reset issue") Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Dong Chenchen <dongchenchen2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/CJCCOKFF4BG2FD7U62KB6TCKIJBCPBKK/ https://gitee.com/src-openeuler/kernel/issues/I7N3N3 Link:https://gitee.com/openeuler/kernel/pulls/1556 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
- 28 7月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Lu Wei <luwei32@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6L365ADXKYRWFSYG3HPROXFVPSGHUTTY/ https://gitee.com/src-openeuler/kernel/issues/I7N3N2 Link:https://gitee.com/openeuler/kernel/pulls/1568 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Lee Jones 提交于
mainline inclusion from mainline-v6.4-rc7 commit 04c55383 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3N2 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c55383fa5689357bcdd2c8036725a55ed632bc -------------------------------- 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> conflict: net/sched/cls_u32.c Signed-off-by: NLu Wei <luwei32@huawei.com>
-
- 27 7月, 2023 3 次提交
-
-
由 M A Ramdhan 提交于
mainline inclusion from mainline-v6.4 commit 0323bce598eea038714f941ce2b22541c46d488f 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/torvalds/linux.git/commit/?id=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> Conflict: net/sched/cls_fw.c Signed-off-by: Ndongchenchen <dongchenchen2@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Longlong Xia <xialonglong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TUVVFQUDMHOOCKGRZ5V2L6BODB3T276K/ https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 Link:https://gitee.com/openeuler/kernel/pulls/1549 Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 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> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Ntong tiangen <tongtiangen@huawei.com> Reviewed-by: NNanyong Sun <sunnanyong@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
-
- 25 7月, 2023 4 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjialin11 https://gitee.com/openeuler/kernel/issues/I7M52S Link:https://gitee.com/openeuler/kernel/pulls/1534 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Wei Li <liwei391@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Wang ShaoBo 提交于
hulk inclusion category: bugfix bugzilla: 187154, https://gitee.com/openeuler/kernel/issues/I7M52S CVE: NA -------------------------------- Fix mpam memleak issue found by kmemleak: unreferenced object 0xffff204000d1d000 (size 128): comm "cpuhp/24", pid 132, jiffies 4294896121 (age 146328.256s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000dd76fed3>] __kmalloc+0x478/0x664 [<00000000e2fa4b32>] mpam_resctrl_setup_domain+0x290/0x5d0 [<0000000088adc589>] mpam_resctrl_cpu_online+0x14c/0x1d0 [<00000000b223bfaa>] mpam_cpu_online+0x1c8/0x2e4 [<000000004438534a>] cpuhp_invoke_callback+0x1f4/0x11b0 [<0000000049ede841>] cpuhp_thread_fun+0x2b8/0x510 [<000000000d731c73>] smpboot_thread_fn+0x260/0x5a0 [<0000000093c61bad>] kthread+0x27c/0x350 [<00000000379f0572>] ret_from_fork+0x10/0x18 There are two cases causing memleak: 1. When offline all cpus of a domain in mpam_resctrl_cpu_offline(), we only free domain's space but not the space of ctrl_val array. 2. When allocating ctrl_val array failed in mpam_resctrl_setup_domain(), the space of ctrl_val array may not be freed. Fixes: 88371f8b ("arm64/mpam: resctrl: Handle cpuhp and resctrl_dom allocation") Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: Nliaoyu <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhengchao Shao <shaozhengchao@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WXOHRQHPIRWXZTKJ26Z6FSX2AX7ALOWX/ https://gitee.com/src-openeuler/kernel/issues/I7N3MX Link:https://gitee.com/openeuler/kernel/pulls/1529 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
由 Pedro Tammela 提交于
mainline inclusion from mainline-v6.5-rc2 commit 3e337087c3b5805fe0b8a46ba622a962880b5d64 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3MX CVE: CVE-2023-3611 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64 --------------------------- Lion says: ------- In the QFQ scheduler a similar issue to CVE-2023-31436 persists. Consider the following code in net/sched/sch_qfq.c: static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sk_buff **to_free) { unsigned int len = qdisc_pkt_len(skb), gso_segs; // ... if (unlikely(cl->agg->lmax < len)) { pr_debug("qfq: increasing maxpkt from %u to %u for class %u", cl->agg->lmax, len, cl->common.classid); err = qfq_change_agg(sch, cl, cl->agg->class_weight, len); if (err) { cl->qstats.drops++; return qdisc_drop(skb, sch, to_free); } // ... } Similarly to CVE-2023-31436, "lmax" is increased without any bounds checks according to the packet length "len". Usually this would not impose a problem because packet sizes are naturally limited. This is however not the actual packet length, rather the "qdisc_pkt_len(skb)" which might apply size transformations according to "struct qdisc_size_table" as created by "qdisc_get_stab()" in net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc. A user may choose virtually any size using such a table. As a result the same issue as in CVE-2023-31436 can occur, allowing heap out-of-bounds read / writes in the kmalloc-8192 cache. ------- We can create the issue with the following commands: tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \ overhead 999999999 linklayer ethernet qfq tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k tc filter add dev $DEV parent 1: matchall classid 1:1 ping -I $DEV 1.1.1.2 This is caused by incorrectly assuming that qdisc_pkt_len() returns a length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX. Fixes: 462dbc91 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: NLion <nnamrec@gmail.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NPedro Tammela <pctammela@mojatatu.com> Reviewed-by: NSimon Horman <simon.horman@corigine.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Conflicts: net/sched/sch_qfq.c Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
-
- 24 7月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @leoliu-oc There are some issues that need to be resolved for Zhaoxin Platform. So remove Zhaoxin uncore code first. ### Issue https://gitee.com/openeuler/kernel/issues/I7LXCE ### Test NA ### Known Issue NA ### Default config change NA Link:https://gitee.com/openeuler/kernel/pulls/1474 Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Cai Xinchen <caixinchen1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/CDXL6ZE3KXTCFMM7YK2X5W3WEV3HTB7G/ https://gitee.com/src-openeuler/kernel/issues/I635JD Link:https://gitee.com/openeuler/kernel/pulls/1498 Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-
- 20 7月, 2023 3 次提交
-
-
由 Hyunwoo Kim 提交于
stable inclusion from stable-v4.19.285 commit 7bb9c6e05efcecb15b0354d574efbc36ca321d75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD CVE: CVE-2022-45886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7bb9c6e05efcecb15b0354d574efbc36ca321d75 -------------------------------- [ Upstream commit 4172385b ] A race condition may occur between the .disconnect function, which is called when the device is disconnected, and the dvb_device_open() function, which is called when the device node is open()ed. This results in several types of UAFs. The root cause of this is that you use the dvb_device_open() function, which does not implement a conditional statement that checks 'dvbnet->exit'. So, add 'remove_mutex` to protect 'dvbnet->exit' and use locked_dvb_net_open() function to check 'dvbnet->exit'. [mchehab: fix a checkpatch warning] Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.comSigned-off-by: NHyunwoo Kim <imv4bel@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @LiuYongQiang0816 two patches from Zheng Yejian Link:https://gitee.com/openeuler/kernel/pulls/1444 Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/A46YSUGPFWTYNDQDDIBLVTYQP7CWKM7I/ https://gitee.com/src-openeuler/kernel/issues/I7ISR1 Link:https://gitee.com/openeuler/kernel/pulls/1469 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
-