- Jul 28, 2022
-
-
Jan Kara authored
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Currently we remove EA inode from mbcache as soon as its xattr refcount drops to zero. However there can be pending attempts to reuse the inode and thus refcount handling code has to handle the situation when refcount increases from zero anyway. So save some work and just keep EA inode in mbcache until it is getting evicted. At that moment we are sure following iget() of EA inode will fail anyway (or wait for eviction to finish and load things from the disk again) and so removing mbcache entry at that moment is fine and simplifies the code a bit. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Jan Kara authored
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused - mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Jan Kara authored
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Do not reclaim entries that are currently used by somebody from a shrinker. Firstly, these entries are likely useful. Secondly, we will need to keep such entries to protect pending increment of xattr block refcount. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 26, 2022
-
-
Yang Jihong authored
mainline inclusion from mainline-v5.19-rc7 commit 68e3c69803dada336893640110cb87221bb01dcf category: bugfix bugzilla: 187299, https://gitee.com/src-openeuler/kernel/issues/I5ISXP CVE: NA -------------------------------- Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress. Fixes: 9bb5d40c ("perf: Fix mmap() accounting hole") Reported-by:
Yang Jihong <yangjihong1@huawei.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by:
Yang Jihong <yangjihong1@huawei.com> Link: https://lkml.kernel.org/r/YsQ3jm2GR38SW7uD@worktop.programming.kicks-ass.net Signed-off-by:
Yang Jihong <yangjihong1@huawei.com> Reviewed-by:
Kuohai Xu <xukuohai@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 25, 2022
-
-
Amir Goldstein authored
mainline inclusion from mainline-v5.19-rc1 commit a32e697cda27679a0327ae2cafdad8c7170f548f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IGXM CVE: NA -------------------------------- The inotify mask flags IN_ONESHOT and IN_EXCL_UNLINK are not "internal to kernel" and should be exposed in procfs fdinfo so CRIU can restore them. Fixes: 69335996 ("inotify: hide internal kernel bits from fdinfo") Link: https://lore.kernel.org/r/20220422120327.3459282-2-amir73il@gmail.com Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Li Nan <linan122@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Laibin Qiu <qiulaibin@huawei.com>
-
- Jul 22, 2022
-
-
Jens Axboe authored
stable inclusion from stable-v5.10.118 commit 3c48558be571e01f67e65edcf03193484eeb2b79 category: bugfix bugzilla: 187134, https://gitee.com/openeuler/kernel/issues/I5HEXY CVE: NA -------------------------------- Lee reports that there's a use-after-free of the process file table. There's an assumption that we don't need the file table for some variants of statx invocation, but that turns out to be false and we end up with not grabbing a reference for the request even if the deferred execution uses it. Get rid of the REQ_F_NO_FILE_TABLE optimization for statx, and always grab that reference. This issues doesn't exist upstream since the native workers got introduced with 5.12. Link: https://lore.kernel.org/io-uring/YoOJ%2FT4QRKC+fAZE@google.com/ Reported-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Zhengchao Shao authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5HWKR CVE: NA -------------------------------- Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5 LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html Reported-by:
<syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Conflict: net/bpf/test_run.c Reviewed-by:
Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/r/20220715115559.139691-1-shaozhengchao@huawei.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 21, 2022
-
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Compare taskgroup 'util_avg' in perferred cpu with capacity preferred cpu, dynamicly adjust cpu range for task wakeup process. Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Add 'prefer_cpus' sysfs and related interface in cgroup cpuset. Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Hui Tang authored
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Dynamic affinity set preferred cpus for task. When the utilization of taskgroup's preferred cpu is low, task only run in cpus preferred to enhance cpu resource locality and reduce interference between task cgroups, otherwise task can burst preferred cpus to use external cpu within cpus allowed. Signed-off-by:
Hui Tang <tanghui20@huawei.com> Reviewed-by:
Zhang Qiao <zhangqiao22@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Zhengchao Shao authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GEVR CVE: NA -------------------------------- When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error: BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00? Fixes: 416d8220 ("crypto: hisilicon - add HiSilicon SEC V2 driver") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Zheyu Ma authored
stable inclusion from stable-v4.19.238 commit 1aea36a62f0a0ad67eccc945bac0bd6422ef720f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GKWU CVE: CVE-2022-2380 -------------------------------- When the sm712fb driver writes three bytes to the framebuffer, the driver will crash: BUG: unable to handle page fault for address: ffffc90001ffffff RIP: 0010:smtcfb_write+0x454/0x5b0 Call Trace: vfs_write+0x291/0xd60 ? do_sys_openat2+0x27d/0x350 ? __fget_light+0x54/0x340 ksys_write+0xce/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix it by removing the open-coded endianness fixup-code. Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Xia Longlong <xialonglong1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Helge Deller authored
stable inclusion from stable-v4.19.238 commit 1caa40af491dcfe17b3ae870a854388d8ea01984 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GKWU CVE: CVE-2022-2380 -------------------------------- Zheyu Ma reported this crash in the sm712fb driver when reading three bytes from the framebuffer: BUG: unable to handle page fault for address: ffffc90001ffffff RIP: 0010:smtcfb_read+0x230/0x3e0 Call Trace: vfs_read+0x198/0xa00 ? do_sys_openat2+0x27d/0x350 ? __fget_light+0x54/0x340 ksys_read+0xce/0x190 do_syscall_64+0x43/0x90 Fix it by removing the open-coded endianess fixup-code and by moving the pointer post decrement out the fb_readl() function. Reported-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
Helge Deller <deller@gmx.de> Tested-by:
Zheyu Ma <zheyuma97@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Xia Longlong <xialonglong1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 20, 2022
-
-
Zhang Wensheng authored
hulk inclusion category: bugfix bugzilla: 187025, https://gitee.com/src-openeuler/kernel/issues/I5HPS5 CVE: NA -------------------------------- Kasan report a bug like below: [ 494.865170] ================================================================== [ 494.901335] BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x234/0x6f0 [ses] [ 494.901347] Write of size 1 at addr ffff8882f3181a70 by task systemd-udevd/1704 [ 494.931929] i801_smbus 0000:00:1f.4: SPD Write Disable is set [ 494.944092] CPU: 12 PID: 1704 Comm: systemd-udevd Tainted: G [ 494.944101] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 7.01 11/13/2019 [ 494.964003] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt [ 494.978532] Call Trace: [ 494.978544] dump_stack+0xbe/0xf9 [ 494.978558] print_address_description.constprop.0+0x19/0x130 [ 495.092838] ? ses_enclosure_data_process+0x234/0x6f0 [ses] [ 495.092846] __kasan_report.cold+0x68/0x80 [ 495.092855] ? __kasan_kmalloc.constprop.0+0x71/0xd0 [ 495.092862] ? ses_enclosure_data_process+0x234/0x6f0 [ses] [ 495.092868] kasan_report+0x3a/0x50 [ 495.092875] ses_enclosure_data_process+0x234/0x6f0 [ses] [ 495.092882] ? mutex_unlock+0x1d/0x40 [ 495.092889] ses_intf_add+0x57f/0x910 [ses] [ 495.092900] class_interface_register+0x26d/0x290 [ 495.092906] ? class_destroy+0xd0/0xd0 [ 495.092912] ? 0xffffffffc0bf8000 [ 495.092919] ses_init+0x18/0x1000 [ses] [ 495.092927] do_one_initcall+0xcb/0x370 [ 495.092934] ? initcall_blacklisted+0x1b0/0x1b0 [ 495.092942] ? create_object.isra.0+0x330/0x3a0 [ 495.092950] ? kasan_unpoison_shadow+0x33/0x40 [ 495.092957] ? kasan_unpoison_shadow+0x33/0x40 [ 495.092966] do_init_module+0xe4/0x3a0 [ 495.092972] load_module+0xd0a/0xdd0 [ 495.092980] ? layout_and_allocate+0x300/0x300 [ 495.092989] ? seccomp_run_filters+0x1d6/0x2c0 [ 495.092999] ? kernel_read_file_from_fd+0xb3/0xe0 [ 495.093006] __se_sys_finit_module+0x11b/0x1b0 [ 495.093012] ? __ia32_sys_init_module+0x40/0x40 [ 495.093023] ? __audit_syscall_entry+0x226/0x290 [ 495.093032] do_syscall_64+0x33/0x40 [ 495.093041] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 495.093046] RIP: 0033:0x7f39c3376089 [ 495.093054] Code: 00 48 81 c4 80 00 00 00 89 f0 c3 66 0f 1f 44 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 8b 0d e7 dd 0b 00 f7 d8 64 89 01 48 [ 495.093058] RSP: 002b:00007ffdc6009e18 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 495.093068] RAX: ffffffffffffffda RBX: 000055d4192801c0 RCX: 00007f39c3376089 [ 495.093072] RDX: 0000000000000000 RSI: 00007f39c2fae99d RDI: 000000000000000f [ 495.093076] RBP: 00007f39c2fae99d R08: 0000000000000000 R09: 0000000000000001 [ 495.093080] R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000000 [ 495.093084] R13: 000055d419282e00 R14: 0000000000020000 R15: 000055d41927f1f0 [ 495.093091] Allocated by task 1704: [ 495.093098] kasan_save_stack+0x1b/0x40 [ 495.093105] __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 495.093111] ses_enclosure_data_process+0x65d/0x6f0 [ses] [ 495.093117] ses_intf_add+0x57f/0x910 [ses] [ 495.093123] class_interface_register+0x26d/0x290 [ 495.093129] ses_init+0x18/0x1000 [ses] [ 495.093134] do_one_initcall+0xcb/0x370 [ 495.093139] do_init_module+0xe4/0x3a0 [ 495.093144] load_module+0xd0a/0xdd0 [ 495.093150] __se_sys_finit_module+0x11b/0x1b0 [ 495.093155] do_syscall_64+0x33/0x40 [ 495.093162] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 495.093168] The buggy address belongs to the object at ffff8882f3181a40 which belongs to the cache kmalloc-64 of size 64 [ 495.093173] The buggy address is located 48 bytes inside of 64-byte region [ffff8882f3181a40, ffff8882f3181a80) [ 495.093175] The buggy address belongs to the page: [ 495.093181] page:ffffea000bcc6000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f3180 [ 495.093186] head:ffffea000bcc6000 order:2 compound_mapcount:0 compound_pincount:0 [ 495.093194] flags: 0x17ffe0000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff) [ 495.093204] raw: 017ffe0000010200 ffffea0016e5fb08 ffffea0016921508 ffff888100050e00 [ 495.093211] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 [ 495.093213] page dumped because: kasan: bad access detected [ 495.093216] Memory state around the buggy address: [ 495.093222] ffff8882f3181900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 495.093227] ffff8882f3181980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 495.093231] >ffff8882f3181a00: fc fc fc fc fc fc fc fc 00 00 00 00 01 fc fc fc [ 495.093234] ^ [ 495.093239] ffff8882f3181a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 495.093244] ffff8882f3181b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 495.093246] ================================================================== After analysis on vmcore, it was found that the line "desc_ptr[len] = '\0';" has slab-out-of-bounds problem in ses_enclosure_data_process. In ses_enclosure_data_process, "desc_ptr" point to "buf", so it have to be limited in the memory of "buf", however. although there is "desc_ptr >= buf + page7_len" judgment, it does not work because "desc_ptr + 4 + len" may bigger than "buf + page7_len", which will lead to slab-out-of-bounds problem. Signed-off-by:
Zhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Eric Biggers authored
stable inclusion from linux-4.19.238 commit b2001eb10f59363da930cdd6e086a2861986fa18 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5EWKO CVE: NA -------------------------------- [ Upstream commit 0f69288253e9fc7c495047720e523b9f1aba5712 ] kobjects aren't supposed to be deleted before their child kobjects are deleted. Apparently this is usually benign; however, a WARN will be triggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Fix this by moving the kobject_del() and the corresponding kobject_uevent() to the correct place. Fixes: 2c2086af ("block: Protect less code with sysfs_lock in blk_{un,}register_queue()") Reviewed-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220124215938.2769-3-ebiggers@kernel.org Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org> Conflict: block/blk-sysfs.c Signed-off-by:
Zhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
liubo authored
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GN7K CVE: NA -------------------------------- In the do_swapcache_reclaim interface, there are the following local variables. unsigned long nr[MAX_NUMNODES], unsigned long nr_to_reclaim[MAX_NUMNODES], struct list_head swapcache_list[MAX_NUMNODES], In the kernel, MAX_NUMNODES is defined as follows: Under the x86_64 architecture, CONFIG_NODES_SHIFT is defined as follows: CONFIG_NODES_SHIFT=10 Therefore, under the X86_64 architecture, local variables may cause kernel stack overflow. Modify the above variable acquisition method and change it to dynamic application. Signed-off-by:
liubo <liubo254@huawei.com> Reviewed-by:
Miaohe Lin <linmiaohe@huawei.com> Reviewed-by:
wangkefeng <wangkefeng.wang@huawei.com> Signed-off-by:
Laibin Qiu <qiulaibin@huawei.com>
-
liubo authored
euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GN7K CVE: NA -------------------------------- In the do_swapcache_reclaim interface, there is a slab-out-of-bounds kasan problem; The reason for the problem is that when list_for_each_entry_safe_reverse_from traverses the LRU linked list, it does not consider that next may be equal to the head address, which may lead to the head address being accessed as the page address, causing problems. In response to the above problems, add a judgment about whether pos is head. Signed-off-by:
liubo <liubo254@huawei.com> Reviewed-by:
Miaohe Lin <linmiaohe@huawei.com> Reviewed-by:
wangkefeng <wangkefeng.wang@huawei.com> Signed-off-by:
Laibin Qiu <qiulaibin@huawei.com>
-
余快 authored
mainline inclusion from mainline-v5.19-rc1 commit 2895f1831e911ca87d4efdf43e35eb72a0c7e66e category: bugfix bugzilla: 187081, https://gitee.com/src-openeuler/kernel/issues/I5H341 CVE: NA -------------------------------- Otherwise io will hung because request will only be completed if the cmd has the flag 'NBD_CMD_INFLIGHT'. Fixes: 07175cb1baf4 ("nbd: make sure request completion won't concurrent") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20220521073749.3146892-4-yukuai3@huawei.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Conflict: fake timeout is not supported yet, clear_bit() in nbd_handle_reply() directly. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 186731, https://gitee.com/src-openeuler/kernel/issues/I5HWTF CVE: NA -------------------------------- If new configuration is submitted while a bio is throttled, then new waiting time is recaculated regardless that the bio might aready wait for some time: tg_conf_updated throtl_start_new_slice tg_update_disptime throtl_schedule_next_dispatch Then io hung can be triggered by always submmiting new configuration before the throttled bio is dispatched. Fix the problem by respecting the time that throttled bio aready waited. In order to do that, instead of start new slice in tg_conf_updated(), just update 'bytes_disp' and 'io_disp' based on the new configuration. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 186769, https://gitee.com/openeuler/kernel/issues/I5FYJY CVE: NA -------------------------------- Our test report a crash: run fstests generic/349 at 2022-05-20 20:55:10 sd 3:0:0:0: Power-on or device reset occurred BUG: kernel NULL pointer dereference, address: 0000000000000030 Call Trace: disk_release+0x42/0x170 device_release+0x92/0x120 kobject_put+0x183/0x350 put_disk+0x23/0x30 sg_device_destroy+0x77/0xd0 sg_remove_device+0x1b8/0x220 device_del+0x19b/0x610 ? kfree_const+0x3e/0x50 ? kobject_put+0x1d1/0x350 device_unregister+0x36/0xa0 __scsi_remove_device+0x1ba/0x240 scsi_forget_host+0x95/0xd0 scsi_remove_host+0xba/0x1f0 sdebug_driver_remove+0x30/0x110 [scsi_debug] device_release_driver_internal+0x1ab/0x340 device_release_driver+0x16/0x20 bus_remove_device+0x167/0x220 device_del+0x23e/0x610 device_unregister+0x36/0xa0 sdebug_do_remove_host+0x159/0x190 [scsi_debug] scsi_debug_exit+0x2d/0x120 [scsi_debug] __se_sys_delete_module+0x34c/0x420 ? exit_to_user_mode_prepare+0x93/0x210 __x64_sys_delete_module+0x1a/0x30 do_syscall_64+0x4d/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Such crash happened since commit 2a19b28f7929 ("blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()") was backported from mainline. commit 61a35cfc2633 ("block: hold a request_queue reference for the lifetime of struct gendisk") is not backported, thus we can't ensure request_queue still exist in disk_release(), and that's why blk_mq_cancel_work_sync() will triggered the problem in disk_release(). However, in order to backport it, there are too many relied patches and kabi will be broken. Since we didn't backport related patches to tear down file system I/O in del_gendisk, which fix issues introduced by refactor patches to move bdi from request_queue to the disk, there is no need to call blk_mq_cancel_work_sync() from disk_release(). This patch just remove blk_mq_cancel_work_sync() from disk_release() to fix the above crash. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
mainline inclusion from mainline-v5.19-rc1 commit ddc25c86b466d2359b57bc7798f167baa1735a44 category: bugfix bugzilla: 186769, https://gitee.com/openeuler/kernel/issues/I5FYJY CVE: NA -------------------------------- bfq_has_work() is using busy_queues currently, which is not accurate because bfq_queue is busy doesn't represent that it has requests. Since bfqd aready has a counter 'queued' to record how many requests are in bfq, use it instead of busy_queues. Noted that bfq_has_work() can be called with 'bfqd->lock' held, thus the lock can't be held in bfq_has_work() to protect 'bfqd->queued'. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220513023507.2625717-3-yukuai3@huawei.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 186769, https://gitee.com/openeuler/kernel/issues/I5FYJY CVE: NA -------------------------------- Our test report a following crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 6 PID: 265 Comm: kworker/6:1H Kdump: loaded Tainted: G O 5.10.0-60.17.0.h43.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:blk_mq_delay_run_hw_queues+0xb6/0xe0 RSP: 0018:ffffacc6803d3d88 EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff99e2c3d25008 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff99e2c911ae18 RBP: ffffacc6803d3dd8 R08: 0000000000000000 R09: ffff99e2c0901f6c R10: 0000000000000018 R11: 0000000000000018 R12: ffff99e2c911ae18 R13: 0000000000000000 R14: 0000000000000003 R15: ffff99e2c911ae18 FS: 0000000000000000(0000) GS:ffff99e6bbf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000007460a006 CR4: 00000000003706e0 Call Trace: __blk_mq_do_dispatch_sched+0x2a7/0x2c0 ? newidle_balance+0x23e/0x2f0 __blk_mq_sched_dispatch_requests+0x13f/0x190 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x47/0xd0 process_one_work+0x1b0/0x350 worker_thread+0x49/0x300 ? rescuer_thread+0x3a0/0x3a0 kthread+0xfe/0x140 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30 After digging from vmcore, I found that the queue is cleaned up(blk_cleanup_queue() is done) and tag set is freed(blk_mq_free_tag_set() is done). There are two problems here: 1) blk_mq_delay_run_hw_queues() will only be called from __blk_mq_do_dispatch_sched() if e->type->ops.has_work() return true. This seems impossible because blk_cleanup_queue() is done, and there should be no io. However, bfq_has_work() can return true even if no io is queued. This is because bfq_has_work() is using busy queues, and bfq_queue can stay busy after dispatching all the requests. 2) 'hctx->run_work' still exists after blk_cleanup_queue(). blk_mq_cancel_work_sync() is called from blk_cleanup_queue() to cancel all the 'run_work'. However, there is no guarantee that new 'run_work' won't be queued after that(and before blk_mq_exit_queue() is done). The first problem is not the root cause, this patch just fix the second problem by grabbing 'q_usage_counter' before queuing 'hctx->run_work'. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Ming Lei authored
mainline inclusion from mainline-v5.16-rc2 commit 2a19b28f7929866e1cec92a3619f4de9f2d20005 category: bugfix bugzilla: 186769, https://gitee.com/openeuler/kernel/issues/I5FYJY CVE: NA -------------------------------- For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed. Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release(): 1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity. 2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity. [1] kernel panic log [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055] <TASK> [12622.918394] scsi_mq_get_budget+0x1a/0x110 [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404] ? pick_next_task_fair+0x39/0x390 [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0 [12622.949593] process_one_work+0x1e8/0x3c0 [12622.954059] worker_thread+0x50/0x3b0 [12622.958144] ? rescuer_thread+0x370/0x370 [12622.962616] kthread+0x158/0x180 [12622.966218] ? set_kthread_struct+0x40/0x40 [12622.970884] ret_from_fork+0x22/0x30 [12622.974875] </TASK> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_wdt mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug] Reported-by:
ChanghuiZhong <czhong@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: linux-scsi@vger.kernel.org Signed-off-by:
Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20211116014343.610501-1-ming.lei@redhat.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Conflicts: ./block/blk-mq.c ./block/blk-mq.h ./block/blk-sysfs.c ./block/genhd.c ./block/blk-core.c Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Yang Yang authored
mainline inclusion from mainline-v5.10-rc1 commit 47ce030b category: bugfix bugzilla: 186769, https://gitee.com/openeuler/kernel/issues/I5FYJY CVE: NA -------------------------------- blk_exit_queue will free elevator_data, while blk_mq_run_work_fn will access it. Move cancel of hctx->run_work to the front of blk_exit_queue to avoid use-after-free. Fixes: 1b97871b ("blk-mq: move cancel of hctx->run_work into blk_mq_hw_sysfs_release") Signed-off-by:
Yang Yang <yang.yang@vivo.com> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Baokun Li authored
hulk inclusion category: bugfix bugzilla: 187222, https://gitee.com/openeuler/kernel/issues/I5H3KE CVE: NA -------------------------------- Hulk Robot reported a BUG: ================================================================== kernel BUG at fs/ext4/extents_status.c:762! invalid opcode: 0000 [#1] SMP KASAN PTI [...] Call Trace: ext4_cache_extents+0x238/0x2f0 ext4_find_extent+0x785/0xa40 ext4_fiemap+0x36d/0xe90 do_vfs_ioctl+0x6af/0x1200 [...] ================================================================== Above issue may happen as follows: ------------------------------------- cpu1 cpu2 _____________________|_____________________ do_vfs_ioctl ext4_ioctl ext4_ioctl_setflags ext4_ind_migrate do_vfs_ioctl ioctl_fiemap ext4_fiemap ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) ext4_fill_fiemap_extents down_write(&EXT4_I(inode)->i_data_sem); ext4_ext_check_inode ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS) memset(ei->i_data, 0, sizeof(ei->i_data)) up_write(&EXT4_I(inode)->i_data_sem); down_read(&EXT4_I(inode)->i_data_sem); ext4_find_extent ext4_cache_extents ext4_es_cache_extent BUG_ON(end < lblk) We can easily reproduce this problem with the syzkaller testcase: ``` 02:37:07 executing program 3: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) ioctl$FS_IOC_FSSETXATTR(r0, 0x40086602, &(0x7f0000000080)={0x17e}) mkdirat(0xffffffffffffff9c, &(0x7f00000000c0)='./file1\x00', 0x1ff) r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='./file1\x00', 0x0, 0x0) ioctl$FS_IOC_FIEMAP(r1, 0xc020660b, &(0x7f0000000180)={0x0, 0x1, 0x0, 0xef3, 0x6, []}) (async, rerun: 32) ioctl$FS_IOC_FSSETXATTR(r1, 0x40086602, &(0x7f0000000140)={0x17e}) (rerun: 32) ``` To solve this issue, we use __generic_block_fiemap() instead of generic_block_fiemap() and add inode_lock_shared to avoid race condition. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 14, 2022
-
-
余快 authored
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- Commit f20a726b ("block: Fix warning in bd_link_disk_holder()") moves the setting of flag 'GENHD_FL_UP' behind blkdev_get, which will disabled part scan: devcie_add_disk register_disk blkdev_get __blkdev_get bdev_get_gendisk get_gendisk -> failed because 'GENHD_FL_UP' is not set And this will cause tests block/017, block/018 and scsi/004 to fail. Fix the problem by moving part scan as well. Fixes: f20a726b ("block: Fix warning in bd_link_disk_holder()") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit b6113052. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit b2f0e44f. Because it will introduce following problem in ltp zram tests: BUG: unable to handle kernel NULL pointer dereference at 0000000000000600 PGD 0 P4D 0 Oops: 0002 [#1] SMP PTI CPU: 28 PID: 172121 Comm: sh Kdump: loaded Tainted: G OE --------- - - 4.18.0+ #2 Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 5.15 05/21/2019 RIP: 0010:flush_disk+0x1d/0x50 RSP: 0018:ffffaf14a516fe20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff899e26bac380 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff899e26bac380 RBP: ffff899e26bac380 R08: 00000000000006a9 R09: 0000000000000004 R10: ffff89cd878ff440 R11: 0000000000000001 R12: 0000000000000000 R13: ffff899e26bac398 R14: ffffaf14a516ff00 R15: ffff89cd8709c3e0 FS: 00007f78d6840740(0000) GS:ffff89fcbf480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000600 CR3: 000000308afc0002 CR4: 00000000001606e0 Call Trace: revalidate_disk+0x57/0x80 reset_store+0xaf/0x120 [zram] kernfs_fop_write+0x10f/0x190 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca This is because "bdev->bd_disk" is not ensured to exist, just convert "set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags)" to "set_bit(GD_NEED_PART_SCAN, &bdev->bd_disk->state)" is wrong. The reason to backport it is that commit 2a57456c8973 ("block: Fix warning in bd_link_disk_holder()") has a regression that part scan is disabled in device_add_disk(), and this problem will be fixed in later patch. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
余快 authored
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit 64ba823f. The patches that broke kabi will be reverted together. Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Zheng Yejian authored
hulk inclusion category: bugfix bugzilla: 187209, https://gitee.com/openeuler/kernel/issues/I5GWFT CVE: NA -------------------------------- Syzkaller report a softlockup problem, see following logs: [ 41.463870] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksoftirqd/0:9] [ 41.509763] Modules linked in: [ 41.512295] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 4.19.90 #13 [ 41.516134] Hardware name: linux,dummy-virt (DT) [ 41.519182] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 41.522415] pc : perf_trace_buf_alloc+0x138/0x238 [ 41.525583] lr : perf_trace_buf_alloc+0x138/0x238 [ 41.528656] sp : ffff8000c137e880 [ 41.531050] x29: ffff8000c137e880 x28: ffff20000850ced0 [ 41.534759] x27: 0000000000000000 x26: ffff8000c137e9c0 [ 41.538456] x25: ffff8000ce5c2ae0 x24: ffff200008358b08 [ 41.542151] x23: 0000000000000000 x22: ffff2000084a50ac [ 41.545834] x21: ffff8000c137e880 x20: 000000000000001c [ 41.549516] x19: ffff7dffbfdf88e8 x18: 0000000000000000 [ 41.553202] x17: 0000000000000000 x16: 0000000000000000 [ 41.556892] x15: 1ffff00036e07805 x14: 0000000000000000 [ 41.560592] x13: 0000000000000004 x12: 0000000000000000 [ 41.564315] x11: 1fffefbff7fbf120 x10: ffff0fbff7fbf120 [ 41.568003] x9 : dfff200000000000 x8 : ffff7dffbfdf8904 [ 41.571699] x7 : 0000000000000000 x6 : ffff0fbff7fbf121 [ 41.575398] x5 : ffff0fbff7fbf121 x4 : ffff0fbff7fbf121 [ 41.579086] x3 : ffff20000850cdc8 x2 : 0000000000000008 [ 41.582773] x1 : ffff8000c1376000 x0 : 0000000000000100 [ 41.586495] Call trace: [ 41.588922] perf_trace_buf_alloc+0x138/0x238 [ 41.591912] perf_ftrace_function_call+0x1ac/0x248 [ 41.595123] ftrace_ops_no_ops+0x3a4/0x488 [ 41.597998] ftrace_graph_call+0x0/0xc [ 41.600715] rcu_dynticks_curr_cpu_in_eqs+0x14/0x70 [ 41.603962] rcu_is_watching+0xc/0x20 [ 41.606635] ftrace_ops_no_ops+0x240/0x488 [ 41.609530] ftrace_graph_call+0x0/0xc [ 41.612249] __read_once_size_nocheck.constprop.0+0x1c/0x38 [ 41.615905] unwind_frame+0x140/0x358 [ 41.618597] walk_stackframe+0x34/0x60 [ 41.621359] __save_stack_trace+0x204/0x3b8 [ 41.624328] save_stack_trace+0x2c/0x38 [ 41.627112] __kasan_slab_free+0x120/0x228 [ 41.630018] kasan_slab_free+0x10/0x18 [ 41.632752] kfree+0x84/0x250 [ 41.635107] skb_free_head+0x70/0xb0 [ 41.637772] skb_release_data+0x3f8/0x730 [ 41.640626] skb_release_all+0x50/0x68 [ 41.643350] kfree_skb+0x84/0x278 [ 41.645890] kfree_skb_list+0x4c/0x78 [ 41.648595] __dev_queue_xmit+0x1a4c/0x23a0 [ 41.651541] dev_queue_xmit+0x28/0x38 [ 41.654254] ip6_finish_output2+0xeb0/0x1630 [ 41.657261] ip6_finish_output+0x2d8/0x7f8 [ 41.660174] ip6_output+0x19c/0x348 [ 41.663850] mld_sendpack+0x560/0x9e0 [ 41.666564] mld_ifc_timer_expire+0x484/0x8a8 [ 41.669624] call_timer_fn+0x68/0x4b0 [ 41.672355] expire_timers+0x168/0x498 [ 41.675126] run_timer_softirq+0x230/0x7a8 [ 41.678052] __do_softirq+0x2d0/0xba0 [ 41.680763] run_ksoftirqd+0x110/0x1a0 [ 41.683512] smpboot_thread_fn+0x31c/0x620 [ 41.686429] kthread+0x2c8/0x348 [ 41.688927] ret_from_fork+0x10/0x18 Look into above call stack, we found a recursive call in 'ftrace_graph_call', see a snippet: __read_once_size_nocheck.constprop.0 ftrace_graph_call ...... rcu_dynticks_curr_cpu_in_eqs ftrace_graph_call We analyze that 'rcu_dynticks_curr_cpu_in_eqs' should not be tracable, and we verify that mark related functions as 'notrace' can avoid the problem. Comparing mainline kernel, we find that commit ff5c4f5c ("rcu/tree: Mark the idle relevant functions noinstr") mark related functions as 'noinstr' which implies notrace, noinline and sticks things in the .noinstr.text section. Link: https://lore.kernel.org/all/20200416114706.625340212@infradead.org/ Currently 'noinstr' mechanism has not been introduced, so we would not directly backport that commit (otherwise more changes may be introduced). Instead, we mark the functions as 'notrace' where it is 'noinstr' in that commit. Signed-off-by:
Zheng Yejian <zhengyejian1@huawei.com> Reviewed-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Jul 13, 2022
-
-
Pablo Neira Ayuso authored
mainline inclusion from mainline-v5.19-rc6 commit 7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6 category: bugfix bugzilla: 187147, https://gitee.com/src-openeuler/kernel/issues/I5GCQH CVE: CVE-2022-34918 -------------------------------- Make sure element data type and length do not mismatch the one specified by the set declaration. Fixes: 7d740264 ("netfilter: nf_tables: variable sized set element keys / data") Reported-by:
Hugues ANGUELKOV <hanguelkov@randorisec.fr> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> conflict: net/netfilter/nf_tables_api.c Signed-off-by:
Lu Wei <luwei32@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Duoming Zhou authored
stable inclusion from stable-v4.19.251 commit 2661f2d88f40e35791257d73def0319b4560b74b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5FNWN CVE: CVE-2022-2318 -------------------------------- commit 9cc02ede696272c5271a401e4f27c262359bc2f6 upstream. There are UAF bugs in rose_heartbeat_expiry(), rose_timer_expiry() and rose_idletimer_expiry(). The root cause is that del_timer() could not stop the timer handler that is running and the refcount of sock is not managed properly. One of the UAF bugs is shown below: (thread 1) | (thread 2) | rose_bind | rose_connect | rose_start_heartbeat rose_release | (wait a time) case ROSE_STATE_0 | rose_destroy_socket | rose_heartbeat_expiry rose_stop_heartbeat | sock_put(sk) | ... sock_put(sk) // FREE | | bh_lock_sock(sk) // USE The sock is deallocated by sock_put() in rose_release() and then used by bh_lock_sock() in rose_heartbeat_expiry(). Although rose_destroy_socket() calls rose_stop_heartbeat(), it could not stop the timer that is running. The KASAN report triggered by POC is shown below: BUG: KASAN: use-after-free in _raw_spin_lock+0x5a/0x110 Write of size 4 at addr ffff88800ae59098 by task swapper/3/0 ... Call Trace: <IRQ> dump_stack_lvl+0xbf/0xee print_address_description+0x7b/0x440 print_report+0x101/0x230 ? irq_work_single+0xbb/0x140 ? _raw_spin_lock+0x5a/0x110 kasan_report+0xed/0x120 ? _raw_spin_lock+0x5a/0x110 kasan_check_range+0x2bd/0x2e0 _raw_spin_lock+0x5a/0x110 rose_heartbeat_expiry+0x39/0x370 ? rose_start_heartbeat+0xb0/0xb0 call_timer_fn+0x2d/0x1c0 ? rose_start_heartbeat+0xb0/0xb0 expire_timers+0x1f3/0x320 __run_timers+0x3ff/0x4d0 run_timer_softirq+0x41/0x80 __do_softirq+0x233/0x544 irq_exit_rcu+0x41/0xa0 sysvec_apic_timer_interrupt+0x8c/0xb0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1b/0x20 RIP: 0010:default_idle+0xb/0x10 RSP: 0018:ffffc9000012fea0 EFLAGS: 00000202 RAX: 000000000000bcae RBX: ffff888006660f00 RCX: 000000000000bcae RDX: 0000000000000001 RSI: ffffffff843a11c0 RDI: ffffffff843a1180 RBP: dffffc0000000000 R08: dffffc0000000000 R09: ffffed100da36d46 R10: dfffe9100da36d47 R11: ffffffff83cf0950 R12: 0000000000000000 R13: 1ffff11000ccc1e0 R14: ffffffff8542af28 R15: dffffc0000000000 ... Allocated by task 146: __kasan_kmalloc+0xc4/0xf0 sk_prot_alloc+0xdd/0x1a0 sk_alloc+0x2d/0x4e0 rose_create+0x7b/0x330 __sock_create+0x2dd/0x640 __sys_socket+0xc7/0x270 __x64_sys_socket+0x71/0x80 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 152: kasan_set_track+0x4c/0x70 kasan_set_free_info+0x1f/0x40 ____kasan_slab_free+0x124/0x190 kfree+0xd3/0x270 __sk_destruct+0x314/0x460 rose_release+0x2fa/0x3b0 sock_close+0xcb/0x230 __fput+0x2d9/0x650 task_work_run+0xd6/0x160 exit_to_user_mode_loop+0xc7/0xd0 exit_to_user_mode_prepare+0x4e/0x80 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x4f/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This patch adds refcount of sock when we use functions such as rose_start_heartbeat() and so on to start timer, and decreases the refcount of sock when timer is finished or deleted by functions such as rose_stop_heartbeat() and so on. As a result, the UAF bugs could be mitigated. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Duoming Zhou <duoming@zju.edu.cn> Tested-by:
Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220629002640.5693-1-duoming@zju.edu.cn Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Xu Jia <xujia39@huawei.com> Reviewed-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Oleksandr Tyshchenko authored
mainline inclusion from mainline-v5.19-rc6 commit b75cd218274e01d026dc5240e86fdeb44bbed0c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5G5TV CVE: CVE-2022-33744 -------------------------------- xen/arm: Fix race in RB-tree based P2M accounting During the PV driver life cycle the mappings are added to the RB-tree by set_foreign_p2m_mapping(), which is called from gnttab_map_refs() and are removed by clear_foreign_p2m_mapping() which is called from gnttab_unmap_refs(). As both functions end up calling __set_phys_to_machine_multi() which updates the RB-tree, this function can be called concurrently. There is already a "p2m_lock" to protect against concurrent accesses, but the problem is that the first read of "phys_to_mach.rb_node" in __set_phys_to_machine_multi() is not covered by it, so this might lead to the incorrect mappings update (removing in our case) in RB-tree. In my environment the related issue happens rarely and only when PV net backend is running, the xen_add_phys_to_mach_entry() claims that it cannot add new pfn <-> mfn mapping to the tree since it is already exists which results in a failure when mapping foreign pages. But there might be other bad consequences related to the non-protected root reads such use-after-free, etc. While at it, also fix the similar usage in __pfn_to_mfn(), so initialize "struct rb_node *n" with the "p2m_lock" held in both functions to avoid possible bad consequences. This is CVE-2022-33744 / XSA-406. Signed-off-by:
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by:
Stefano Stabellini <sstabellini@kernel.org> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Zhao Wenhui <zhaowenhui8@huawei.com> Reviewed-by:
Chen Hui <judy.chenhui@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Jiri Slaby authored
stable inclusion from stable-4.19.250 commit b15d5731b708a2190fec836990b8aefbbf36b07a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GKVX CVE: CVE-2021-33656 -------------------------------- commit ff2047fb755d4415ec3c70ac799889371151796d upstream. Drop support for these ioctls: * PIO_FONT, PIO_FONTX * GIO_FONT, GIO_FONTX * PIO_FONTRESET As was demonstrated by commit 90bfdeef (tty: make FONTX ioctl use the tty pointer they were actually passed), these ioctls are not used from userspace, as: 1) they used to be broken (set up font on current console, not the open one) and racy (before the commit above) 2) KDFONTOP ioctl is used for years instead Note that PIO_FONTRESET is defunct on most systems as VGA_CONSOLE is set on them for ages. That turns on BROKEN_GRAPHICS_PROGRAMS which makes PIO_FONTRESET just return an error. We are removing KD_FONT_FLAG_OLD here as it was used only by these removed ioctls. kd.h header exists both in kernel and uapi headers, so we can remove the kernel one completely. Everyone includeing kd.h will now automatically get the uapi one. There are now unused definitions of the ioctl numbers and "struct consolefontdesc" in kd.h, but as it is a uapi header, I am not touching these. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210105120239.28031-8-jslaby@suse.cz Cc: guodaxing <guodaxing@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Luo Meng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GRX6 CVE: NA -------------------------------- Fault inject on pool metadata device report: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easy reproduce: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If metadata commit failed, the transaction will be aborted and the metadata space manager will be destroyed. If load table on this pool, when register the metadata threshold callback, the UAF will happen on metadata space manager. So return error when load table if the pool is on FAIL status. Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Luo Meng <luomeng12@huawei.com> Reviewed-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Roger Pau Monne authored
stable inclusion from stable-v4.19.251 commit 981de55fb6b5253fa7ae345827c6c3ca77912e5c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GM0S CVE: CVE-2022-33742 -------------------------------- commit 2400617da7eebf9167d71a46122828bc479d64c9 upstream. Split the current bounce buffering logic used with persistent grants into it's own option, and allow enabling it independently of persistent grants. This allows to reuse the same code paths to perform the bounce buffering required to avoid leaking contiguous data in shared pages not part of the request fragments. Reporting whether the backend is to be trusted can be done using a module parameter, or from the xenstore frontend path as set by the toolstack when adding the device. This is CVE-2022-33742, part of XSA-403. Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
ChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-
Roger Pau Monne authored
stable inclusion from stable-v4.19.251 commit 4b67d8e42dbba42cfafe22ac3e4117d9573fdd74 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GM0S CVE: CVE-2022-33741 -------------------------------- commit 4491001c2e0fa69efbb748c96ec96b100a5cdb7e upstream. Bounce all data on the skbs to be transmitted into zeroed pages if the backend is untrusted. This avoids leaking data present in the pages shared with the backend but not part of the skb fragments. This requires introducing a new helper in order to allocate skbs with a size multiple of XEN_PAGE_SIZE so we don't leak contiguous data on the granted pages. Reporting whether the backend is to be trusted can be done using a module parameter, or from the xenstore frontend path as set by the toolstack when adding the device. This is CVE-2022-33741, part of XSA-403. Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
ChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com>
-