- May 07, 2022
-
-
Ronnie Sahlberg authored
stable inclusion from linux-4.19.233 commit 2fe0e281f7ad0a62259649764228227dd6b2561d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A CVE: NA -------------------------------- [ Upstream commit 3d6cc9898efdfb062efb74dc18cfc700e082f5d5 ] When cifs_get_root() fails during cifs_smb3_do_mount() we call deactivate_locked_super() which eventually will call delayed_free() which will free the context. In this situation we should not proceed to enter the out: section in cifs_smb3_do_mount() and free the same resources a second time. [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0 [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10 [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40 [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170 [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20 [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae [Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by:
Shyam Prasad N <sprasad@microsoft.com> Reviewed-by:
Shyam Prasad N <sprasad@microsoft.com> Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- May 06, 2022
-
-
david regan authored
stable inclusion from stable-v4.19.231 commit c48771b7f7b086bca5a1094191b33c3c4324bf0b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5646A CVE: N/A ------------------------------------------------ [ Upstream commit 36415a7964711822e63695ea67fede63979054d9 ] The brcmnand driver contains a bug in which if a page (example 2k byte) is read from the parallel/ONFI NAND and within that page a subpage (512 byte) has correctable errors which is followed by a subpage with uncorrectable errors, the page read will return the wrong status of correctable (as opposed to the actual status of uncorrectable.) The bug is in function brcmnand_read_by_pio where there is a check for uncorrectable bits which will be preempted if a previous status for correctable bits is detected. The fix is to stop checking for bad bits only if we already have a bad bits status. Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by:
david regan <dregan@mail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/trinity-478e0c09-9134-40e8-8f8c-31c371225eda-1643237024774@3c-app-mailcom-lxa02 Signed-off-by:
Sasha Levin <sashal@kernel.org> Conflicts: drivers/mtd/nand/raw/brcmnand/brcmnand.c Signed-off-by:
Cui GaoSheng <cuigaosheng1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Thomas Gleixner authored
mainline inclusion from mainline-v5.3-rc1 commit 7652ac92 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I563FS CVE: NA -------------------------------- The pinning of sensitive CR0 and CR4 bits caused a boot crash when loading the kvm_intel module on a kernel compiled with CONFIG_PARAVIRT=n. The reason is that the static key which controls the pinning is marked RO after init. The kvm_intel module contains a CR4 write which requires to update the static key entry list. That obviously does not work when the key is in a RO section. With CONFIG_PARAVIRT enabled this does not happen because the CR4 write uses the paravirt indirection and the actual write function is built in. As the key is intended to be immutable after init, move native_write_cr0/4() out of line. While at it consolidate the update of the cr4 shadow variable and store the value right away when the pinning is initialized on a booting CPU....
-
Kees Cook authored
mainline inclusion from mainline-v5.3-rc1 commit 8dbec27a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I563FS CVE: NA -------------------------------- With sensitive CR4 bits pinned now, it's possible that the WP bit for CR0 might become a target as well. Following the same reasoning for the CR4 pinning, pin CR0's WP bit. Contrary to the cpu feature dependend CR4 pinning this can be done with a constant value. Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: kernel-hardening@lists.openwall.com Link: https://lkml.kernel.org/r/20190618045503.39105-4-keescook@chromium.org Signed-off-by:
Lin Yujun <linyujun809@huawei.com> Reviewed-by:
Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Kees Cook authored
mainline inclusion from mainline-v5.3-rc1 commit 873d50d5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I563FS CVE: NA -------------------------------- Several recent exploits have used direct calls to the native_write_cr4() function to disable SMEP and SMAP before then continuing their exploits using userspace memory access. Direct calls of this form can be mitigate by pinning bits of CR4 so that they cannot be changed through a common function. This is not intended to be a general ROP protection (which would require CFI to defend against properly), but rather a way to avoid trivial direct function calling (or CFI bypasses via a matching function prototype) as seen in: https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html (https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-7308 ) The goals of this change: - Pin specific bits (SMEP, SMAP, and UMIP) when writing CR4. - Avoid setting the bits too early (they must become pinned only after CPU feature detection and selection has finished). - Pinning mask needs to be read-only during normal runtime. - Pinning needs to be checked after write to validate the cr4 state Using __ro_after_init on the mask is done so it can't be first disabled with a malicious write. Since these bits are global state (once established by the boot CPU and kernel boot parameters), they are safe to write to secondary CPUs before those CPUs have finished feature detection. As such, the bits are set at the first cr4 write, so that cr4 write bugs can be detected (instead of silently papered over). This uses a few bytes less storage of a location we don't have: read-only per-CPU data. A check is performed after the register write because an attack could just skip directly to the register write. Such a direct jump is possible because of how this function may be built by the compiler (especially due to the removal of frame pointers) where it doesn't add a stack frame (function exit may only be a retq without pops) which is sufficient for trivial exploitation like in the timer overwrites mentioned above). The asm argument constraints gain the "+" modifier to convince the compiler that it shouldn't make ordering assumptions about the arguments or memory, and treat them as changed. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: kernel-hardening@lists.openwall.com Link: https://lkml.kernel.org/r/20190618045503.39105-3-keescook@chromium.org Signed-off-by:
Lin Yujun <linyujun809@huawei.com> Reviewed-by:
Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Ma Wupeng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Add more debug info about memory reliable if oom occurs. Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Ma Wupeng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Previous reliable task used does not contains reliable pagecache pages if pagecache use reliable memory feature is disabled. This will lead to incorrect result because reliable task's pagecache is allocated from mirrored region. With this patch, reliable task used will always contains reliable anon pages and reliable pagecache pages. Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Ma Wupeng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S CVE: NA -------------------------------- Show corrent reliable pagecache size if /proc/meminfo if memory reliable and pagecache use reliable memory is enabled. Fixes: 9f07eb30 ("mm: Add space after ReliableFileCache") Signed-off-by:
Ma Wupeng <mawupeng1@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 29, 2022
-
-
Lin Ma authored
stable inclusion from stable-v4.19.223 commit b68f41c6320b2b7fbb54a95f07a69f3dc7e56c59 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I55483 CVE: CVE-2022-1195 ------------------------------------------------- commit b2f37aead1b82a770c48b5d583f35ec22aabb61e upstream. The previous commit 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev") reorder the kfree operations and unregister_netdev operation to prevent UAF. This commit improves the previous one by also deferring the nullify of the ax->tty pointer. Otherwise, a NULL pointer dereference bug occurs. Partial of the stack trace is shown below. BUG: kernel NULL pointer dereference, address: 0000000000000538 RIP: 0010:ax_xmit+0x1f9/0x400 ... Call Trace: dev_hard_start_xmit+0xec/0x320 sch_direct_xmit+0xea/0x240 __qdisc_run+0x166/0x5c0 __dev_queue_xmit+0x2c7/0xaf0 ax25_std_establish_data_link+0x59/0x60 ax25_connect+0x3a0/0x500 ? security_socket_connect+0x2b/0x40 __sys_connect+0x96/0xc0 ? __hrtimer_init+0xc0/0xc0 ? common_nsleep+0x2e/0x50 ? switch_fpu_return+0x139/0x1a0 __x64_sys_connect+0x11/0x20 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The crash point is shown as below static void ax_encaps(...) { ... set_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags); // ax->tty = NULL! ... } By placing the nullify action after the unregister_netdev, the ax->tty pointer won't be assigned as NULL net_device framework layer is well synchronized. Signed-off-by:
Lin Ma <linma@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Lin Ma authored
stable inclusion from stable-v4.19.223 commit 896193a02a2981e60c40d4614fd095ce92135ccd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I55483 CVE: CVE-2022-1195 ------------------------------------------------- commit 3e0588c291d6ce225f2b891753ca41d45ba42469 upstream. There is a possible race condition (use-after-free) like below (USE) | (FREE) ax25_sendmsg | ax25_queue_xmit | dev_queue_xmit | __dev_queue_xmit | __dev_xmit_skb | sch_direct_xmit | ... xmit_one | netdev_start_xmit | tty_ldisc_kill __netdev_start_xmit | mkiss_close ax_xmit | kfree ax_encaps | | Even though there are two synchronization primitives before the kfree: 1. wait_for_completion(&ax->dead). This can prevent the race with routines from mkiss_ioctl. However, it cannot stop the routine coming from upper layer, i.e., the ax25_sendmsg. 2. netif_stop_queue(ax->dev). It seems that this line of code aims to halt the transmit queue but it fails to stop the routine that already being xmit. This patch reorder the kfree after the unregister_netdev to avoid the possible UAF as the unregister_netdev() is well synchronized and won't return if there is a running routine. Signed-off-by:
Lin Ma <linma@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hangyu Hua authored
stable inclusion from stable-v4.19.238 commit a8bba9fd73775e66b4021b18f2193f769ce48a59 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I51YBN CVE: CVE-2022-28389 ------------------------------------------------- commit 04c9b00ba83594a29813d6b1fb8fdc93a3915174 upstream. There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 51f3baad ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/20220311080208.45047-1-hbh25y@gmail.com Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Eric Dumazet authored
stable inclusion from stable-v4.19.237 commit c106f9aa6cd8913af9188ad361899ae696b5de37 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I51YBN CVE: CVE-2022-28356 ------------------------------------------------- commit 2d327a79ee176930dc72c131a970c891d367c1dc upstream. My latest patch, attempting to fix the refcount leak in a minimal way turned out to add a new bug. Whenever the bind operation fails before we attempt to grab a reference count on a device, we might release the device refcount of a prior successful bind() operation. syzbot was not happy about this [1]. Note to stable teams: Make sure commit b37a46683739 ("netdevice: add the case if dev is NULL") is already present in your trees. [1] general protection fault, probably for non-canonical address 0xdffffc0000000070: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 1 PID: 3590 Comm: syz-executor361 Tainted: G W 5.17.0-syzkaller-04796-g169e77764adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:llc_ui_connect+0x400/0xcb0 net/llc/af_llc.c:500 Code: 80 3c 02 00 0f 85 fc 07 00 00 4c 8b a5 38 05 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 80 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a9 07 00 00 49 8b b4 24 80 03 00 00 4c 89 f2 48 RSP: 0018:ffffc900038cfcc0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff8880756eb600 RCX: 0000000000000000 RDX: 0000000000000070 RSI: ffffc900038cfe3e RDI: 0000000000000380 RBP: ffff888015ee5000 R08: 0000000000000001 R09: ffff888015ee5535 R10: ffffed1002bdcaa6 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc900038cfe37 R14: ffffc900038cfe38 R15: ffff888015ee5012 FS: 0000555555acd300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000280 CR3: 0000000077db6000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __sys_connect_file+0x155/0x1a0 net/socket.c:1900 __sys_connect+0x161/0x190 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x6f/0xb0 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f016acb90b9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd417947f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f016acb90b9 RDX: 0000000000000010 RSI: 0000000020000140 RDI: 0000000000000003 RBP: 00007f016ac7d0a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f016ac7d130 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:llc_ui_connect+0x400/0xcb0 net/llc/af_llc.c:500 Fixes: 764f4eb6846f ("llc: fix netdevice reference leaks in llc_ui_bind()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Cc: 赵子轩 <beraphin@gmail.com> Cc: Stoyan Manolov <smanolov@suse.de> Link: https://lore.kernel.org/r/20220325035827.360418-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Yajun Deng authored
stable inclusion from stable-v4.19.238 commit 574a12b4445076a04499962ce8b8ae15f75a7955 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I51YBN CVE: CVE-2022-28356 ------------------------------------------------- commit b37a466837393af72fe8bcb8f1436410f3f173f3 upstream. Add the case if dev is NULL in dev_{put, hold}, so the caller doesn't need to care whether dev is NULL or not. Signed-off-by:
Yajun Deng <yajun.deng@linux.dev> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Pavel Machek <pavel@denx.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Eric Dumazet authored
stable inclusion from stable-v4.19.237 commit d14193111c436fc5de33206c67c7afd45c730099 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I51YBN CVE: CVE-2022-28356 ------------------------------------------------- commit 764f4eb6846f5475f1244767d24d25dd86528a4a upstream. Whenever llc_ui_bind() and/or llc_ui_autobind() took a reference on a netdevice but subsequently fail, they must properly release their reference or risk the infamous message from unregister_netdevice() at device dismantle. unregister_netdevice: waiting for eth0 to become free. Usage count = 3 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
赵子轩 <beraphin@gmail.com> Reported-by:
Stoyan Manolov <smanolov@suse.de> Link: https://lore.kernel.org/r/20220323004147.1990845-1-eric.dumazet@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Huang Guobin <huangguobin4@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 28, 2022
-
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.235 commit 691f354689e94571853c79ac3d7d6e7f27dfb87b category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 6c7cb60bff7aec24b834343ff433125f469886a3 upstream. When building for Thumb2, the vectors make use of a local label. Sadly, the Spectre BHB code also uses a local label with the same number which results in the Thumb2 reference pointing at the wrong place. Fix this by changing the number used for the Spectre BHB local label. Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Tested-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Randy Dunlap authored
stable inclusion from stable-v4.19.235 commit d60f27d6ff8a8d28441b44cd2e8a2fda64c99aac category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 68453767131a5deec1e8f9ac92a9042f929e585d upstream. When CONFIG_GENERIC_CPU_VULNERABILITIES is not set, references to spectre_v2_update_state() cause a build error, so provide an empty stub for that function when the Kconfig option is not set. Fixes this build error: arm-linux-gnueabi-ld: arch/arm/mm/proc-v7-bugs.o: in function `cpu_v7_bugs_init': proc-v7-bugs.c:(.text+0x52): undefined reference to `spectre_v2_update_state' arm-linux-gnueabi-ld: proc-v7-bugs.c:(.text+0x82): undefined reference to `spectre_v2_update_state' Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: patches@armlinux.org.uk Acked-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 623ca876d4a91665b7d948e399f5776c713722ea category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit b1a384d2cbccb1eb3f84765020d25e2c1929706e upstream. The kernel test robot discovered that building without HARDEN_BRANCH_PREDICTOR issues a warning due to a missing argument to pr_info(). Add the missing argument. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 9dd78194a372 ("ARM: report Spectre v2 status through sysfs") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Nathan Chancellor authored
stable inclusion from stable-v4.19.234 commit 868d5f8a428f41da7f493a6744913b55c5c97ee2 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa upstream. ld.lld does not support the NOCROSSREFS directive at the moment, which breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB workaround"): ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS Support for this directive will eventually be implemented, at which point a version check can be added. To avoid breaking the build in the meantime, just define NOCROSSREFS to nothing when using ld.lld, with a link to the issue for tracking. Cc: stable@vger.kernel.org Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Link: https://github.com/ClangBuiltLinux/linux/issues/1609 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 8dd98efe9e3f20927a2970bed5974ca8c3646c92 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 33970b031dc4653cc9dc80f2886976706c4c8ef1 upstream. In the recent Spectre BHB patches, there was a typo that is only exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have been mcr p15,0,XX,c7,c5,4 Reported-by:
kernel test robot <lkp@intel.com> Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Emmanuel Gil Peyrot authored
stable inclusion from stable-v4.19.234 commit fffcf80d055c4f619ae9cd8bf3a8b67319317100 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 330f4c53d3c2d8b11d86ec03a964b86dc81452f5 upstream. It was missing a semicolon. Signed-off-by:
Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Fixes: 25875aa71dfe ("ARM: include unprivileged BPF status in Spectre V2 reporting"). Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 29db7e4b67fccf5e1fe28ec89f2add90ce74d77b category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 25875aa71dfefd1959f07e626c4d285b88b27ac2 upstream. The mitigations for Spectre-BHB are only applied when an exception is taken, but when unprivileged BPF is enabled, userspace can load BPF programs that can be used to exploit the problem. When unprivileged BPF is enabled, report the vulnerable status via the spectre_v2 sysfs file. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 99e14db3b711c27f93079ba9d7f2fff169916d5f category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream. Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as well to be safe, which is affected by Spectre V2 in the same ways as Cortex-A15. Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [changes due to lack of SYSTEM_FREEING_INITMEM - gregkh] Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 67e1f18a972be16363c6e88d7b29cde880774164 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 8d9d651ff2270a632e9dc497b142db31e8911315 upstream. Use the linker's LOADADDR() macro to get the load address of the sections, and provide a macro to set the start and end symbols. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit 45c25917ceb7a5377883ef4c3a675276fba8a268 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 04e91b7324760a377a725e218b5ee783826d30f5 upstream. Provide a couple of helpers to copy the vectors and stubs, and also to flush the copied vectors and stubs. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Russell King (Oracle) authored
stable inclusion from stable-v4.19.234 commit dc64af755099d1e51fd64e99fe3a59b75595814a category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 9dd78194a3722fa6712192cdd4f7032d45112a9a upstream. As per other architectures, add support for reporting the Spectre vulnerability status via sysfs CPU. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> [ preserve res variable and add SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED - gregkh ] Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 26, 2022
-
-
Hangyu Hua authored
mainline inclusion from mainline-v5.18-rc1 commit 3d3925ff6433f98992685a9679613a2cc97f3ce2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I51YBQ CVE: CVE-2022-28388 ------------------------------------------------- There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 0024d8ad ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/all/20220311080614.45229-1-hbh25y@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Conflicts: drivers/net/can/usb/usb_8dev.c Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 24, 2022
-
-
Yang Jihong authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I53VHE CVE: NA -------------------------------- This reverts commit 03804742. This patch is used to solve race between close() and fork() of the perf. However, this patch is not accepted by the community. As a result, destory interface is incorrectly invoked during the perf_remove_from_context, causing UAF, see https://lkml.org/lkml/2019/6/28/856 . For 4.19 kernel, he final fix patch has been incorporated, see eb41044b. Therefore, need to revert the patch. Signed-off-by:
Yang Jihong <yangjihong1@huawei.com> Reviewed-by:
Kuohai Xu <xukuohai@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 22, 2022
-
-
Duoming Zhou authored
mainline inclusion from mainline-v5.18-rc1 commit fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I53VJO CVE: CVE-2022-1205 -------------------------------- The previous commit 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect") move ax25_disconnect into lock_sock() in order to prevent NPD bugs. But there are race conditions that may lead to null pointer dereferences in ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(), ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we use ax25_kill_by_device() to detach the ax25 device. One of the race conditions that cause null pointer dereferences can be shown as below: (Thread 1) | (Thread 2) ax25_connect() | ax25_std_establish_data_link() | ax25_start_t1timer() | mod_timer(&ax25->t1timer,..) | | ax25_kill_by_device() (wait a time) | ... | s->ax25_dev = NULL; //(1) ax25_t1timer_expiry() | ax25->ax25_dev->values[..] //(2)| ... ... | We set null to ax25_cb->ax25_dev in position (1) and dereference the null pointer in position (2). The corresponding fail log is shown below: =============================================================== BUG: kernel NULL pointer dereference, address: 0000000000000050 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc6-00794-g45690b7d0 RIP: 0010:ax25_t1timer_expiry+0x12/0x40 ... Call Trace: call_timer_fn+0x21/0x120 __run_timers.part.0+0x1ca/0x250 run_timer_softirq+0x2c/0x60 __do_softirq+0xef/0x2f3 irq_exit_rcu+0xb6/0x100 sysvec_apic_timer_interrupt+0xa2/0xd0 ... This patch moves ax25_disconnect() before s->ax25_dev = NULL and uses del_timer_sync() to delete timers in ax25_disconnect(). If ax25_disconnect() is called by ax25_kill_by_device() or ax25->ax25_dev is NULL, the reason in ax25_disconnect() will be equal to ENETUNREACH, it will wait all timers to stop before we set null to s->ax25_dev in ax25_kill_by_device(). Fixes: 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect") Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Conflict: net/ax25/af_ax25.c Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Duoming Zhou authored
mainline inclusion from mainline-v5.17-rc4 commit 7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I53VJO CVE: CVE-2022-1199 -------------------------------- The ax25_disconnect() in ax25_kill_by_device() is not protected by any locks, thus there is a race condition between ax25_disconnect() and ax25_destroy_socket(). when ax25->sk is assigned as NULL by ax25_destroy_socket(), a NULL pointer dereference bug will occur if site (1) or (2) dereferences ax25->sk. ax25_kill_by_device() | ax25_release() ax25_disconnect() | ax25_destroy_socket() ... | if(ax25->sk != NULL) | ... ... | ax25->sk = NULL; bh_lock_sock(ax25->sk); //(1) | ... ... | bh_unlock_sock(ax25->sk); //(2)| This patch moves ax25_disconnect() into lock_sock(), which can synchronize with ax25_destroy_socket() in ax25_release(). Fail log: =============================================================== BUG: kernel NULL pointer dereference, address: 0000000000000088 ... RIP: 0010:_raw_spin_lock+0x7e/0xd0 ... Call Trace: ax25_disconnect+0xf6/0x220 ax25_device_event+0x187/0x250 raw_notifier_call_chain+0x5e/0x70 dev_close_many+0x17d/0x230 rollback_registered_many+0x1f1/0x950 unregister_netdevice_queue+0x133/0x200 unregister_netdev+0x13/0x20 ... Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Conflict: net/ax25/af_ax25.c Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Duoming Zhou authored
stable inclusion from linux-4.19.235 commit 5ab8de9377edde3eaf1de9872e2f01d43157cd6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I53VJO CVE: CVE-2022-1199 -------------------------------- [ Upstream commit 71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac ] When two ax25 devices attempted to establish connection, the requester use ax25_create(), ax25_bind() and ax25_connect() to initiate connection. The receiver use ax25_rcv() to accept connection and use ax25_create_cb() in ax25_rcv() to create ax25_cb, but the ax25_cb->sk is NULL. When the receiver is detaching, a NULL pointer dereference bug caused by sock_hold(sk) in ax25_kill_by_device() will happen. The corresponding fail log is shown below: =============================================================== BUG: KASAN: null-ptr-deref in ax25_device_event+0xfd/0x290 Call Trace: ... ax25_device_event+0xfd/0x290 raw_notifier_call_chain+0x5e/0x70 dev_close_many+0x174/0x220 unregister_netdevice_many+0x1f7/0xa60 unregister_netdevice_queue+0x12f/0x170 unregister_netdev+0x13/0x20 mkiss_close+0xcd/0x140 tty_ldisc_release+0xc0/0x220 tty_release_struct+0x17/0xa0 tty_release+0x62d/0x670 ... This patch add condition check in ax25_kill_by_device(). If s->sk is NULL, it will goto if branch to kill device. Fixes: 4e0f718daf97 ("ax25: improve the incomplete fix to avoid UAF and NPD bugs") Reported-by:
Thomas Osterried <thomas@osterried.de> Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Duoming Zhou authored
stable inclusion from linux-4.19.235 commit 3072e72814de56f3c674650a8af98233ddf78b19 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I53VJO CVE: CVE-2022-1199 -------------------------------- [ Upstream commit 4e0f718daf97d47cf7dec122da1be970f145c809 ] The previous commit 1ade48d0c27d ("ax25: NPD bug when detaching AX25 device") introduce lock_sock() into ax25_kill_by_device to prevent NPD bug. But the concurrency NPD or UAF bug will occur, when lock_sock() or release_sock() dereferences the ax25_cb->sock. The NULL pointer dereference bug can be shown as below: ax25_kill_by_device() | ax25_release() | ax25_destroy_socket() | ax25_cb_del() ... | ... | ax25->sk=NULL; lock_sock(s->sk); //(1) | s->ax25_dev = NULL; | ... release_sock(s->sk); //(2) | ... | The root cause is that the sock is set to null before dereference site (1) or (2). Therefore, this patch extracts the ax25_cb->sock in advance, and uses ax25_list_lock to protect it, which can synchronize with ax25_cb_del() and ensure the value of sock is not null before dereference sites. The concurrency UAF bug can be shown as below: ax25_kill_by_device() | ax25_release() | ax25_destroy_socket() ... | ... | sock_put(sk); //FREE lock_sock(s->sk); //(1) | s->ax25_dev = NULL; | ... release_sock(s->sk); //(2) | ... | The root cause is that the sock is released before dereference site (1) or (2). Therefore, this patch uses sock_hold() to increase the refcount of sock and uses ax25_list_lock to protect it, which can synchronize with ax25_cb_del() in ax25_destroy_socket() and ensure the sock wil not be released before dereference sites. Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Lin Ma authored
stable inclusion from linux-4.19.235 commit bd05a8f1b7368ef4f7845548312fc61ab4fa63ce category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I53VJO CVE: CVE-2022-1199 -------------------------------- commit 1ade48d0c27d5da1ccf4b583d8c5fc8b534a3ac8 upstream. The existing cleanup routine implementation is not well synchronized with the syscall routine. When a device is detaching, below race could occur. static int ax25_sendmsg(...) { ... lock_sock() ax25 = sk_to_ax25(sk); if (ax25->ax25_dev == NULL) // CHECK ... ax25_queue_xmit(skb, ax25->ax25_dev->dev); // USE ... } static void ax25_kill_by_device(...) { ... if (s->ax25_dev == ax25_dev) { s->ax25_dev = NULL; ... } Other syscall functions like ax25_getsockopt, ax25_getname, ax25_info_show also suffer from similar races. To fix them, this patch introduce lock_sock() into ax25_kill_by_device in order to guarantee that the nullify action in cleanup routine cannot proceed when another socket request is pending. Signed-off-by:
Hanjie Wu <nagi@zju.edu.cn> Signed-off-by:
Lin Ma <linma@zju.edu.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Josh Poimboeuf authored
stable inclusion from stable-v4.19.238 commit 9fbfc77d0f5e04a7434fa6d32112036e2a41bc6e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I53TS3 CVE: NA -------------------------------- commit d8dd25a4 upstream. When the current frame address (CFA) is stored on the stack (i.e., cfa->base == CFI_SP_INDIRECT), objtool neglects to adjust the stack offset when there are subsequent pushes or pops. This results in bad ORC data at the end of the ENTER_IRQ_STACK macro, when it puts the previous stack pointer on the stack and does a subsequent push. This fixes the following unwinder warning: WARNING: can't dereference registers at 00000000f0a6bdba for ip interrupt_entry+0x9f/0xa0 Fixes: 627fce14 ("objtool: Add ORC unwind table generation") Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Reported-by:
Dave Jones <dsj@fb.com> Reported-by:
Steven Rostedt <rostedt@goodmis.org> Reported-by: Vegard Nos...
-
Josh Poimboeuf authored
stable inclusion from stable-v4.19.238 commit ac069a960d357a7495fd2a1cde28d9b03250cace category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I53TS3 CVE: NA -------------------------------- commit 1fb14363 upstream. In swapgs_restore_regs_and_return_to_usermode, after the stack is switched to the trampoline stack, the existing UNWIND_HINT_REGS hint is no longer valid, which can result in the following ORC unwinder warning: WARNING: can't dereference registers at 000000003aeb0cdd for ip swapgs_restore_regs_and_return_to_usermode+0x93/0xa0 For full correctness, we could try to add complicated unwind hints so the unwinder could continue to find the registers, but when when it's this close to kernel exit, unwind hints aren't really needed anymore and it's fine to just use an empty hint which tells the unwinder to stop. For consistency, also move the UNWIND_HINT_EMPTY in entry_SYSCALL_64_after_hwframe to a similar location. Fixes: 3e3b9293 ("x86/entry/64: Return to userspace from the trampoline stack") Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Reported-by:
Dave Jones <dsj@fb.com> Reported-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Reported-by:
Joe Mario <jmario@redhat.com> Reported-by:
Jann Horn <jannh@google.com> Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/60ea8f562987ed2d9ace2977502fe481c0d7c9a0.1587808742.git.jpoimboe@redhat.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Zou Yipeng <zouyipeng@huawei.com> Reviewed-by:
Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 21, 2022
-
-
Haimin Zhang authored
stable inclusion from stable-v4.19.238 commit 693fe8af9a2625139de07bd1ae212a7d89c37795 category: bugfix bugzilla: 186606, https://gitee.com/src-openeuler/kernel/issues/I53SSV CVE: CVE-2022-1353 -------------------------------- [ Upstream commit 9a564bccb78a76740ea9d75a259942df8143d02c ] Add __GFP_ZERO flag for compose_sadb_supported in function pfkey_register to initialize the buffer of supp_skb to fix a kernel-info-leak issue. 1) Function pfkey_register calls compose_sadb_supported to request a sk_buff. 2) compose_sadb_supported calls alloc_sbk to allocate a sk_buff, but it doesn't zero it. 3) If auth_len is greater 0, then compose_sadb_supported treats the memory as a struct sadb_supported and begins to initialize. But it just initializes the field sadb_supported_len and field sadb_supported_exttype without field sadb_supported_reserved. Reported-by:
TCS Robot <tcs_robot@tencent.com> Signed-off-by:
Haimin Zhang <tcs_kernel@tencent.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Wang Weiyang <wangweiyang2@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Apr 20, 2022
-
-
James Morse authored
stable inclusion from stable-v4.19.236 commit ed5dec3fae86f20db52930e1d9a7cc38403994cc category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 228a26b912287934789023b4132ba76065d9491c upstream. Future CPUs may implement a clearbhb instruction that is sufficient to mitigate SpectreBHB. CPUs that implement this instruction, but not CSV2.3 must be affected by Spectre-BHB. Add support to use this instruction as the BHB mitigation on CPUs that support it. The instruction is in the hint space, so it will be treated by a NOP as older CPUs. Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> [ modified for stable: Use a KVM vector template instead of alternatives ] Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Joey Gouly authored
stable inclusion from stable-v4.19.236 commit a44e7ddb5822b943cd50c5ad6a2541fb445d58bd category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 9e45365f1469ef2b934f9d035975dbc9ad352116 upstream. This is a new ID register, introduced in 8.7. Signed-off-by:
Joey Gouly <joey.gouly@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Marc Zyngier <maz@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Reiji Watanabe <reijiw@google.com> Acked-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211210165432.8106-3-joey.gouly@arm.com Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
James Morse authored
stable inclusion from stable-v4.19.236 commit 5f051d32b03f08a0507ac1afd7b9c0a30c8e5d59 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit a5905d6af492ee6a4a2205f0d550b3f931b03d03 upstream. KVM allows the guest to discover whether the ARCH_WORKAROUND SMCCC are implemented, and to preserve that state during migration through its firmware register interface. Add the necessary boiler plate for SMCCC_ARCH_WORKAROUND_3. Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> [ kvm code moved to virt/kvm/arm, removed fw regs ABI. Added 32bit stub ] Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: arch/arm/include/asm/kvm_host.h arch/arm64/include/asm/kvm_host.h virt/kvm/arm/psci.c Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
James Morse authored
stable inclusion from stable-v4.19.236 commit c20d551744797000c4af993f7d59ef8c69732949 category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- commit 558c303c9734af5a813739cd284879227f7297d2 upstream. Speculation attacks against some high-performance processors can make use of branch history to influence future speculation. When taking an exception from user-space, a sequence of branches or a firmware call overwrites or invalidates the branch history. The sequence of branches is added to the vectors, and should appear before the first indirect branch. For systems using KPTI the sequence is added to the kpti trampoline where it has a free register as the exit from the trampoline is via a 'ret'. For systems not using KPTI, the same register tricks are used to free up a register in the vectors. For the firmware call, arch-workaround-3 clobbers 4 registers, so there is no choice but to save them to the EL1 stack. This only happens for entry from EL0, so if we take an exception due to the stack access, it will not become re-entrant. For KVM, the existing branch-predictor-hardening vectors are used. When a spectre version of these vectors is in use, the firmware call is sufficient to mitigate against Spectre-BHB. For the non-spectre versions, the sequence of branches is added to the indirect vector. Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@kernel.org> # <v5.17.x 72bb9dcb6c33c arm64: Add Cortex-X2 CPU part definition Cc: <stable@kernel.org> # <v5.16.x 2d0d656700d67 arm64: Add Neoverse-N2, Cortex-A710 CPU part definition Cc: <stable@kernel.org> # <v5.10.x 8a6b88e6 arm64: Add part number for Arm Cortex-A77 [ modified for stable, moved code to cpu_errata.c removed bitmap of mitigations, use kvm template infrastructure ] Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: arch/arm64/Kconfig arch/arm64/include/asm/cpufeature.h arch/arm64/include/asm/cputype.h arch/arm64/kernel/cpu_errata.c Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
James Morse authored
stable inclusion from stable-v4.19.236 commit a68912a3ae3413be5febcaa40e7e0ec1fd62adee category: bugfix bugzilla: 186460, https://gitee.com/src-openeuler/kernel/issues/I53MHA CVE: CVE-2022-23960 -------------------------------- KVM writes the Spectre-v2 mitigation template at the beginning of each vector when a CPU requires a specific sequence to run. Because the template is copied, it can not be modified by the alternatives at runtime. As the KVM template code is intertwined with the bp-hardening callbacks, all templates must have a bp-hardening callback. Add templates for calling ARCH_WORKAROUND_3 and one for each value of K in the brancy-loop. Identify these sequences by a new parameter template_start, and add a copy of install_bp_hardening_cb() that is able to install them. Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: arch/arm64/include/asm/cpucaps.h Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Liao Chang <liaochang1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-