- 20 7月, 2023 4 次提交
-
-
由 Li Lingfeng 提交于
mainline inclusion from mainline-v6.4-rc8 commit 2760904d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7&id=2760904d895279f87196f0fa9ec570c79fe6a2e4 ---------------------------------------- As described in commit 38d11da5 ("dm: don't lock fs when the map is NULL in process of resume"), a deadlock may be triggered between do_resume() and do_mount(). This commit preserves the fix from commit 38d11da5 but moves it to where it also serves to fix a similar deadlock between do_suspend() and do_mount(). It does so, if the active map is NULL, by clearing DM_SUSPEND_LOCKFS_FLAG in dm_suspend() which is called by both do_suspend() and do_resume(). Fixes: 38d11da5 ("dm: don't lock fs when the map is NULL in process of resume") Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Conflicts: drivers/md/dm-ioctl.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 0ba9dcd9)
-
由 Li Lingfeng 提交于
mainline inclusion from mainline-v6.4-rc1 commit 38d11da5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4&id=38d11da522aacaa05898c734a1cec86f1e611129 ---------------------------------------- Commit fa247089 ("dm: requeue IO if mapping table not yet available") added a detection of whether the mapping table is available in the IO submission process. If the mapping table is unavailable, it returns BLK_STS_RESOURCE and requeues the IO. This can lead to the following deadlock problem: dm create mount ioctl(DM_DEV_CREATE_CMD) ioctl(DM_TABLE_LOAD_CMD) do_mount vfs_get_tree ext4_get_tree get_tree_bdev sget_fc alloc_super // got &s->s_umount down_write_nested(&s->s_umount, ...); ext4_fill_super ext4_load_super ext4_read_bh submit_bio // submit and wait io end ioctl(DM_DEV_SUSPEND_CMD) dev_suspend do_resume dm_suspend __dm_suspend lock_fs freeze_bdev get_active_super grab_super // wait for &s->s_umount down_write(&s->s_umount); dm_swap_table __bind // set md->map(can't get here) IO will be continuously requeued while holding the lock since mapping table is NULL. At the same time, mapping table won't be set since the lock is not available. Like request-based DM, bio-based DM also has the same problem. It's not proper to just abort IO if the mapping table not available. So clear DM_SKIP_LOCKFS_FLAG when the mapping table is NULL, this allows the DM table to be loaded and the IO submitted upon resume. Fixes: fa247089 ("dm: requeue IO if mapping table not yet available") Cc: stable@vger.kernel.org Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Conflicts: drivers/md/dm-ioctl.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 14dd9b4d)
-
由 Mike Snitzer 提交于
mainline inclusion from mainline-v5.18-rc1 commit fa247089 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7&id=fa247089de9936a46e290d4724cb5f0b845600f5 ---------------------------------------- Update both bio-based and request-based DM to requeue IO if the mapping table not available. This race of IO being submitted before the DM device ready is so narrow, yet possible for initial table load given that the DM device's request_queue is created prior, that it best to requeue IO to handle this unlikely case. Reported-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit e50475d3)
-
由 Li Lingfeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 -------------------------------- This reverts commit 90d1a836. It's not proper to just abort IO when the map is not ready. So revert this and requeue IO to keep consistent with the community. Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit bc4c0996)
-
- 18 7月, 2023 1 次提交
-
-
由 Zhong Jinghua 提交于
stable inclusion from stable-v5.10.173 commit c79a924ed6afac1708dfd370ba66bcf6a852ced6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7JHOA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c79a924ed6afac1708dfd370ba66bcf6a852ced6 -------------------------------- [ Upstream commit 9f6ad5d5 ] In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should be checked before reassignment, because if an overflow error occurs, the original correct value will be changed to the wrong value, and it will not be changed back. More, the original patch did not solve the problem, the value was set and ioctl returned an error, but the subsequent io used the value in the loop driver, which still caused an alarm: loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos Fixes: c490a0b5 ("loop: Check for overflow while configuring loop") Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit cfb3aa6f)
-
- 12 7月, 2023 1 次提交
-
-
由 Coly Li 提交于
mainline inclusion from mainline-v6.3-rc4 commit 9bbf5fee category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7JLUM CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4&id=9bbf5feecc7eab2c370496c1c161bbfe62084028 ---------------------------------------- This is an already known issue that dm-thin volume cannot be used as swap, otherwise a deadlock may happen when dm-thin internal memory demand triggers swap I/O on the dm-thin volume itself. But thanks to commit a666e5c0 ("dm: fix deadlock when swapping to encrypted device"), the limit_swap_bios target flag can also be used for dm-thin to avoid the recursive I/O when it is used as swap. Fix is to simply set ti->limit_swap_bios to true in both pool_ctr() and thin_ctr(). In my test, I create a dm-thin volume /dev/vg/swap and use it as swap device. Then I run fio on another dm-thin volume /dev/vg/main and use large --blocksize to trigger swap I/O onto /dev/vg/swap. The following fio command line is used in my test, fio --name recursive-swap-io --lockmem 1 --iodepth 128 \ --ioengine libaio --filename /dev/vg/main --rw randrw \ --blocksize 1M --numjobs 32 --time_based --runtime=12h Without this fix, the whole system can be locked up within 15 seconds. With this fix, there is no any deadlock or hung task observed after 2 hours of running fio. Furthermore, if blocksize is changed from 1M to 128M, after around 30 seconds fio has no visible I/O, and the out-of-memory killer message shows up in kernel message. After around 20 minutes all fio processes are killed and the whole system is back to being alive. This is exactly what is expected when recursive I/O happens on dm-thin volume when it is used as swap. Depends-on: a666e5c0 ("dm: fix deadlock when swapping to encrypted device") Cc: stable@vger.kernel.org Signed-off-by: NColy Li <colyli@suse.de> Acked-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Conflict: drivers/md/dm-thin.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 6283fa7e)
-
- 11 7月, 2023 1 次提交
-
-
由 t.feng 提交于
stable inclusion from stable-v5.10.181 commit f4a371d3f5a7a71dff1ab48b3122c5cf23cc7ad5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7GVI1 CVE: CVE-2023-3090 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f4a371d3f5a7a71dff1ab48b3122c5cf23cc7ad5 -------------------------------- [ Upstream commit 90cbed52 ] If skb enqueue the qdisc, fq_skb_cb(skb)->time_to_send is changed which is actually skb->cb, and IPCB(skb_in)->opt will be used in __ip_options_echo. It is possible that memcpy is out of bounds and lead to stack overflow. We should clear skb->cb before ip_local_out or ip6_local_out. v2: 1. clean the stack info 2. use IPCB/IP6CB instead of skb->cb crash on stable-5.10(reproduce in kasan kernel). Stack info: [ 2203.651571] BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x589/0x800 [ 2203.653327] Write of size 4 at addr ffff88811a388f27 by task swapper/3/0 [ 2203.655460] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.10.0-60.18.0.50.h856.kasan.eulerosv2r11.x86_64 #1 [ 2203.655466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-20181220_000000-szxrtosci10000 04/01/2014 [ 2203.655475] Call Trace: [ 2203.655481] <IRQ> [ 2203.655501] dump_stack+0x9c/0xd3 [ 2203.655514] print_address_description.constprop.0+0x19/0x170 [ 2203.655530] __kasan_report.cold+0x6c/0x84 [ 2203.655586] kasan_report+0x3a/0x50 [ 2203.655594] check_memory_region+0xfd/0x1f0 [ 2203.655601] memcpy+0x39/0x60 [ 2203.655608] __ip_options_echo+0x589/0x800 [ 2203.655654] __icmp_send+0x59a/0x960 [ 2203.655755] nf_send_unreach+0x129/0x3d0 [nf_reject_ipv4] [ 2203.655763] reject_tg+0x77/0x1bf [ipt_REJECT] [ 2203.655772] ipt_do_table+0x691/0xa40 [ip_tables] [ 2203.655821] nf_hook_slow+0x69/0x100 [ 2203.655828] __ip_local_out+0x21e/0x2b0 [ 2203.655857] ip_local_out+0x28/0x90 [ 2203.655868] ipvlan_process_v4_outbound+0x21e/0x260 [ipvlan] [ 2203.655931] ipvlan_xmit_mode_l3+0x3bd/0x400 [ipvlan] [ 2203.655967] ipvlan_queue_xmit+0xb3/0x190 [ipvlan] [ 2203.655977] ipvlan_start_xmit+0x2e/0xb0 [ipvlan] [ 2203.655984] xmit_one.constprop.0+0xe1/0x280 [ 2203.655992] dev_hard_start_xmit+0x62/0x100 [ 2203.656000] sch_direct_xmit+0x215/0x640 [ 2203.656028] __qdisc_run+0x153/0x1f0 [ 2203.656069] __dev_queue_xmit+0x77f/0x1030 [ 2203.656173] ip_finish_output2+0x59b/0xc20 [ 2203.656244] __ip_finish_output.part.0+0x318/0x3d0 [ 2203.656312] ip_finish_output+0x168/0x190 [ 2203.656320] ip_output+0x12d/0x220 [ 2203.656357] __ip_queue_xmit+0x392/0x880 [ 2203.656380] __tcp_transmit_skb+0x1088/0x11c0 [ 2203.656436] __tcp_retransmit_skb+0x475/0xa30 [ 2203.656505] tcp_retransmit_skb+0x2d/0x190 [ 2203.656512] tcp_retransmit_timer+0x3af/0x9a0 [ 2203.656519] tcp_write_timer_handler+0x3ba/0x510 [ 2203.656529] tcp_write_timer+0x55/0x180 [ 2203.656542] call_timer_fn+0x3f/0x1d0 [ 2203.656555] expire_timers+0x160/0x200 [ 2203.656562] run_timer_softirq+0x1f4/0x480 [ 2203.656606] __do_softirq+0xfd/0x402 [ 2203.656613] asm_call_irq_on_stack+0x12/0x20 [ 2203.656617] </IRQ> [ 2203.656623] do_softirq_own_stack+0x37/0x50 [ 2203.656631] irq_exit_rcu+0x134/0x1a0 [ 2203.656639] sysvec_apic_timer_interrupt+0x36/0x80 [ 2203.656646] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 2203.656654] RIP: 0010:default_idle+0x13/0x20 [ 2203.656663] Code: 89 f0 5d 41 5c 41 5d 41 5e c3 cc cc cc cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 0f 1f 44 00 00 0f 00 2d 9f 32 57 00 fb f4 <c3> cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 be 08 [ 2203.656668] RSP: 0018:ffff88810036fe78 EFLAGS: 00000256 [ 2203.656676] RAX: ffffffffaf2a87f0 RBX: ffff888100360000 RCX: ffffffffaf290191 [ 2203.656681] RDX: 0000000000098b5e RSI: 0000000000000004 RDI: ffff88811a3c4f60 [ 2203.656686] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff88811a3c4f63 [ 2203.656690] R10: ffffed10234789ec R11: 0000000000000001 R12: 0000000000000003 [ 2203.656695] R13: ffff888100360000 R14: 0000000000000000 R15: 0000000000000000 [ 2203.656729] default_idle_call+0x5a/0x150 [ 2203.656735] cpuidle_idle_call+0x1c6/0x220 [ 2203.656780] do_idle+0xab/0x100 [ 2203.656786] cpu_startup_entry+0x19/0x20 [ 2203.656793] secondary_startup_64_no_verify+0xc2/0xcb [ 2203.657409] The buggy address belongs to the page: [ 2203.658648] page:0000000027a9842f refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11a388 [ 2203.658665] flags: 0x17ffffc0001000(reserved|node=0|zone=2|lastcpupid=0x1fffff) [ 2203.658675] raw: 0017ffffc0001000 ffffea000468e208 ffffea000468e208 0000000000000000 [ 2203.658682] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 2203.658686] page dumped because: kasan: bad access detected To reproduce(ipvlan with IPVLAN_MODE_L3): Env setting: ======================================================= modprobe ipvlan ipvlan_default_mode=1 sysctl net.ipv4.conf.eth0.forwarding=1 iptables -t nat -A POSTROUTING -s 20.0.0.0/255.255.255.0 -o eth0 -j MASQUERADE ip link add gw link eth0 type ipvlan ip -4 addr add 20.0.0.254/24 dev gw ip netns add net1 ip link add ipv1 link eth0 type ipvlan ip link set ipv1 netns net1 ip netns exec net1 ip link set ipv1 up ip netns exec net1 ip -4 addr add 20.0.0.4/24 dev ipv1 ip netns exec net1 route add default gw 20.0.0.254 ip netns exec net1 tc qdisc add dev ipv1 root netem loss 10% ifconfig gw up iptables -t filter -A OUTPUT -p tcp --dport 8888 -j REJECT --reject-with icmp-port-unreachable ======================================================= And then excute the shell(curl any address of eth0 can reach): for((i=1;i<=100000;i++)) do ip netns exec net1 curl x.x.x.x:8888 done ======================================================= Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: N"t.feng" <fengtao40@huawei.com> Suggested-by: NFlorian Westphal <fw@strlen.de> Reviewed-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> (cherry picked from commit 2572b83c)
-
- 05 7月, 2023 3 次提交
-
-
由 Yu Kuai 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188902, https://gitee.com/openeuler/kernel/issues/I7EENU ---------------------------------------- nbd->config = config and refcount_set(&nbd->config_refs, 1) in nbd_genl_connect may be out of order, causing config_refs to be set to 1 first, and then nbd_open accessing nbd->config reports a null pointer reference. T1 T2 vfs_open do_dentry_open blkdev_open blkdev_get __blkdev_get nbd_open nbd_get_config_unlocked genl_rcv_msg genl_family_rcv_msg genl_family_rcv_msg_doit nbd_genl_connect nbd_alloc_and_init_config // out of order execution refcount_set(&nbd->config_refs, 1); // 2 nbd->config // null point nbd->config = config; // 1 Fix it by adding a cpu memory barrier to guarantee sequential execution. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit 0abd5a5d)
-
由 Yu Kuai 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188902, https://gitee.com/openeuler/kernel/issues/I7EENU ---------------------------------------- There are no functional changes, just to make code cleaner and prepare to fix null-ptr-dereference while accessing 'nbd->config'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit db092a15)
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 188902, https://gitee.com/openeuler/kernel/issues/I7EENU ---------------------------------------- There are no functional changes, make the code cleaner and prepare to fix null-ptr-dereference while accessing 'nbd->config'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit d2cdad29)
-
- 04 7月, 2023 2 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.180 commit e9d64e90a0ada4d00ac6562e351ef10ae7d9b911 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F1RG CVE: CVE-2023-35824 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e9d64e90a0ada4d00ac6562e351ef10ae7d9b911 -------------------------------- [ Upstream commit 5abda7a1 ] In dm1105_probe, it called dm1105_ir_init and bound &dm1105->ir.work with dm1105_emit_key. When it handles IRQ request with dm1105_irq, it may call schedule_work to start the work. When we call dm1105_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in dm1105_remove CPU0 CPU1 |dm1105_emit_key dm1105_remove | dm1105_ir_exit | rc_unregister_device | rc_free_device | rc_dev_release | kfree(dev); | | | rc_keydown | //use Fixes: 34d2f9bf ("V4L/DVB: dm1105: use dm1105_dev & dev instead of dm1105dvb") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NPu Lehui <pulehui@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> (cherry picked from commit a7d0cd45)
-
由 Takashi Iwai 提交于
mainline inclusion from mainline-v6.4-rc3 commit b8c75e4a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6YKXB CVE: CVE-2023-31084 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b8c75e4a1b325ea0a9433fa8834be97b5836b946 -------------------------------- Using a semaphore in the wait_event*() condition is no good idea. It hits a kernel WARN_ON() at prepare_to_wait_event() like: do not call blocking ops when !TASK_RUNNING; state=1 set at prepare_to_wait_event+0x6d/0x690 For avoiding the potential deadlock, rewrite to an open-coded loop instead. Unlike the loop in wait_event*(), this uses wait_woken() after the condition check, hence the task state stays consistent. CVE-2023-31084 was assigned to this bug. Link: https://lore.kernel.org/r/CA+UBctCu7fXn4q41O_3=id1+OdyQ85tZY1x+TkT-6OVBL6KAUw@mail.gmail.com/ Link: https://lore.kernel.org/linux-media/20230512151800.1874-1-tiwai@suse.deReported-by: NYu Hao <yhao016@ucr.edu> Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-31084Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com> (cherry picked from commit c008597c)
-
- 03 7月, 2023 1 次提交
-
-
由 Xia Fukun 提交于
stable inclusion from stable-v5.10.173 commit e9743b3052e125c44b555f07f2876a4bdccfd983 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7F2UT CVE: CVE-2023-3220 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e9743b3052e125c44b555f07f2876a4bdccfd983 -------------------------------- [ Upstream commit 93340e10 ] As kzalloc may fail and return NULL pointer, it should be better to check pstates in order to avoid the NULL pointer dereference. Fixes: 25fdd593 ("drm/msm: Add SDM845 DPU support") Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: NAbhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514160/ Link: https://lore.kernel.org/r/20221206080236.43687-1-jiasheng@iscas.ac.cnSigned-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NXia Fukun <xiafukun@huawei.com> (cherry picked from commit 72096ab0)
-
- 30 6月, 2023 1 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.180 commit 7dac96e9cc985328ec1fae92f0c245f559dc0e11 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ERIV CVE: CVE-2023-3327 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7dac96e9cc985328ec1fae92f0c245f559dc0e11 -------------------------------- [ Upstream commit 30cf57da ] In saa7134_initdev, it will call saa7134_hwinit1. There are three function invoking here: saa7134_video_init1, saa7134_ts_init1 and saa7134_vbi_init1. All of them will init a timer with same function. Take saa7134_video_init1 as an example. It'll bound &dev->video_q.timeout with saa7134_buffer_timeout. In buffer_activate, the timer funtcion is started. If we remove the module or device which will call saa7134_finidev to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the timer works accordingly before cleanup in saa7134_finidev. CPU0 CPU1 |saa7134_buffer_timeout saa7134_finidev | kfree(dev); | | | saa7134_buffer_next | //use dev Fixes: 1e7126b4 ("media: saa7134: Convert timers to use timer_setup()") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLonglong Xia <xialonglong1@huawei.com> (cherry picked from commit d046e6f3)
-
- 28 6月, 2023 2 次提交
-
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.4-rc1 commit 2b947f87 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDYS CVE: CVE-2023-35828 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204 -------------------------------- In renesas_usb3_probe, role_work is bound with renesas_usb3_role_work. renesas_usb3_start will be called to start the work. If we remove the driver which will call usbhs_remove, there may be an unfinished work. The possible sequence is as follows: CPU0 CPU1 renesas_usb3_role_work renesas_usb3_remove usb_role_switch_unregister device_unregister kfree(sw) //free usb3->role_sw usb_role_switch_set_role //use usb3->role_sw The usb3->role_sw could be freed under such circumstance and then used in usb_role_switch_set_role. This bug was found by static analysis. And note that removing a driver is a root-only operation, and should never happen in normal case. But the root user may directly remove the device which will also trigger the remove function. Fix it by canceling the work before cleanup in the renesas_usb3_remove. Fixes: 39facfa0 ("usb: gadget: udc: renesas_usb3: Add register of usb role switch") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20230320062931.505170-1-zyytlz.wz@163.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit c6acce6a)
-
由 Jiasheng Jiang 提交于
stable inclusion from stable-v5.10.166 commit 7b4516ba56f1fcb13ffc91912f3074e28362228d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FCLX CVE: CVE-2023-3358 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b4516ba56f1fcb13ffc91912f3074e28362228d ---------------------------------------- [ Upstream commit b3d40c3e ] As the kcalloc may return NULL pointer, it should be better to check the ishtp_dma_tx_map before use in order to avoid NULL pointer dereference. Fixes: 3703f53b ("HID: intel_ish-hid: ISH Transport layer") Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NCai Xinchen <caixinchen1@huawei.com> (cherry picked from commit beefe46c)
-
- 27 6月, 2023 1 次提交
-
-
由 Ma Wupeng 提交于
hulk inclusion category: cleanup bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKXZ CVE: NA -------------------------------- If system have no mirrored memory or use crashkernel.high while kernelcore=mirror is enabled in cmdline, during crashkernel, there will be limited mirrored memory and this usually lead to OOM. To solve this problem, disable mirror feature during crashkernel. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> (cherry picked from commit 2bbd51a7)
-
- 26 6月, 2023 1 次提交
-
-
由 Ma Wupeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F3NP CVE: NA -------------------------------- Efi fake mem support for arm64 is introduced for debug propose only. However efi_memmap_init_late in arm_enable_runtime_services will free this memory which will lead to UAF on efi.memmap.map. In order to slove this, clear efi.memmap.flags to skip free. Since efi map is never freed in arm64, this will not lead to memroy leak. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> (cherry picked from commit 6b455c10)
-
- 25 6月, 2023 1 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.180 commit de19d02d734ef29f5dbd2c12fe810fa960ecd83f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDZ3 CVE: CVE-2023-35829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=de19d02d734ef29f5dbd2c12fe810fa960ecd83f -------------------------------- [ Upstream commit 3228cec2 ] In rkvdec_probe, rkvdec->watchdog_work is bound with rkvdec_watchdog_func. Then rkvdec_vp9_run may be called to start the work. If we remove the module which will call rkvdec_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in rkvdec_remove. CPU0 CPU1 |rkvdec_watchdog_func rkvdec_remove | rkvdec_v4l2_cleanup| v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> (cherry picked from commit df1542dd)
-
- 21 6月, 2023 3 次提交
-
-
由 Zhong Jinghua 提交于
mainline inclusion from mainline-v6.4-rc1 commit 55793ea5 category: bugfix bugzilla: 188268 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=55793ea54d77719a071b1ccc05a05056e3b5e009 ---------------------------------------- We tested and found an alarm caused by nbd_ioctl arg without verification. The UBSAN warning calltrace like below: UBSAN: Undefined behaviour in fs/buffer.c:1709:35 signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x170/0x1dc lib/dump_stack.c:118 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161 handle_overflow+0x188/0x1dc lib/ubsan.c:192 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934 blkdev_writepage+0x34/0x40 fs/block_dev.c:607 __writepage+0x68/0xe8 mm/page-writeback.c:2305 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114 do_writepages+0xd4/0x250 mm/page-writeback.c:2344 The reason for triggering this warning is __block_write_full_page() -> i_size_read(inode) - 1 overflow. inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize. We think it is necessary to limit the size of arg to prevent errors. Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int. Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results. Fix it by adding checks to prevent passing in too large numbers. Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20230206145805.2645671-1-zhongjinghua@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit d2d7ffda)
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.1-rc1 commit dcbddf54 category: bugfix bugzilla: 188268 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dcbddf541f18e367ac9cdad8e223d382cd303161 ---------------------------------------- Move the validation of the block from the callers into nbd_set_size. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit e652b754)
-
由 Zheng Wang 提交于
mainline inclusion from mainline-v6.4-rc1 commit 63264422 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7EK74 CVE: CVE-2023-3141 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=632644227850 -------------------------------- In r592_probe, dev->detect_timer was bound with r592_detect_timer. In r592_irq function, the timer function will be invoked by mod_timer. If we remove the module which will call hantro_release to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in r592_remove. CPU0 CPU1 |r592_detect_timer r592_remove | memstick_free_host| put_device; | kfree(host); | | | queue_work | &host->media_checker //use Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Link: https://lore.kernel.org/r/20230307164338.1246287-1-zyytlz.wz@163.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> (cherry picked from commit 24fbf41b)
-
- 19 6月, 2023 1 次提交
-
-
由 Samuel Thibault 提交于
mainline inclusion from mainline-v6.2-rc7 commit 2b09d5d3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7C2TM CVE: CVE-2023-3161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b09d5d364986f724f17001ccfe4126b9b43a0be -------------------------------- blit_x and blit_y are u32, so fbcon currently cannot support fonts larger than 32x32. The 32x32 case also needs shifting an unsigned int, to properly set bit 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font", as reported on: http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com Kernel Branch: 6.2.0-rc5-next-20230124 Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharingReported-by: NSanan Hasanov <sanan.hasanov@Knights.ucf.edu> Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org> Fixes: 2d2699d9 ("fbcon: font setting should check limitation of driver") Cc: stable@vger.kernel.org Tested-by: NMiko Larsson <mikoxyzzz@gmail.com> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com> (cherry picked from commit aa4e4b8d)
-
- 14 6月, 2023 1 次提交
-
-
由 Wei Li 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q4S3 -------------------------------- When doing "cat /proc/interrupts" after qxl.ko is unloaded, an oops occurs: BUG: unable to handle page fault for address: ffffffffc0274769 PGD 2a0d067 P4D 2a0d067 PUD 2a0f067 PMD 103f39067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 246 Comm: cat Not tainted 6.1.0-rc2 #24 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:string_nocheck+0x34/0x50 Code: 66 85 c0 74 3c 83 e8 01 4c 8d 5c 07 01 31 c0 eb 19 49 39 fa 76 03 44 88 07 48 83 c7 RSP: 0018:ffffc90000893bb8 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffc90000893c50 RCX: ffff0a00ffffff04 RDX: ffffffffc0274769 RSI: ffff888102812000 RDI: ffff88810281133e RBP: ffff888102812000 R08: ffffffff823fa5e6 R09: 0000000000000007 R10: ffff888102812000 R11: ffff88820281133d R12: ffffffffc0274769 R13: ffff0a00ffffff04 R14: 0000000000000cc4 R15: ffffffff823276b4 FS: 000000000214f8c0(0000) GS:ffff88842fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc0274769 CR3: 00000001025c4005 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> string+0x46/0x60 vsnprintf+0x27a/0x4f0 seq_vprintf+0x34/0x50 seq_printf+0x53/0x70 ? seq_read_iter+0x365/0x450 show_interrupts+0x259/0x330 seq_read_iter+0x2a3/0x450 proc_reg_read_iter+0x47/0x70 generic_file_splice_read+0x94/0x160 splice_direct_to_actor+0xb0/0x230 ? do_splice_direct+0xd0/0xd0 do_splice_direct+0x8b/0xd0 do_sendfile+0x345/0x4f0 __x64_sys_sendfile64+0xa1/0xc0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4bb0ce Code: c3 0f 1f 00 4c 89 d2 4c 89 c6 e9 bd fd ff ff 0f 1f 44 00 00 31 c0 c3 0f 1f 44 00 00 RSP: 002b:00007ffd99dc3fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 0000000001000000 RCX: 00000000004bb0ce RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001 RBP: 0000000000000001 R08: 000000000068f240 R09: 0000000001000000 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 </TASK> It seems that qxl doesn't free the interrupt it requests during unload, fix this by adding the missing free_irq(). Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)") Signed-off-by: NWei Li <liwei391@huawei.com> (cherry picked from commit ed64582f)
-
- 13 6月, 2023 1 次提交
-
-
由 Zheng Wang 提交于
stable inclusion from stable-v5.10.177 commit 2b346876b93168541a45551d5f9abd1d26102e89 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7781Q CVE: CVE-2023-33288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2b346876b93168541a45551d5f9abd1d26102e89 -------------------------------- [ Upstream commit 47c29d69 ] In bq24190_probe, &bdi->input_current_limit_work is bound with bq24190_input_current_limit_work. When external power changed, it will call bq24190_charger_external_power_changed to start the work. If we remove the module which will call bq24190_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: CPU0 CPUc1 |bq24190_input_current_limit_work bq24190_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_get_property_from_supplier | //use Fix it by finishing the work before cleanup in the bq24190_remove Fixes: 97774672 ("power_supply: Initialize changed_work before calling device_add") Signed-off-by: NZheng Wang <zyytlz.wz@163.com> Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Conflicts: drivers/power/supply/bq24190_charger.c Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com> (cherry picked from commit 085b94ff)
-
- 08 6月, 2023 6 次提交
-
-
由 Zhong Jinghua 提交于
hulk inclusion category: bugfix bugzilla: 188799, https://gitee.com/openeuler/kernel/issues/I79QWO CVE: NA ---------------------------------------- Config->socks in sock_shutdown may trigger a UAF problem. The reason is that sock_shutdown does not hold the config_lock, so that nbd_ioctl can release config->socks at this time. T0: NBD_SET_SOCK T1: NBD_DO_IT T0 T1 nbd_ioctl mutex_lock(&nbd->config_lock) // get lock __nbd_ioctl nbd_start_device_ioctl nbd_start_device mutex_unlock(&nbd->config_lock) // relase lock wait_event_interruptible (kill, enter sock_shutdown) sock_shutdown nbd_ioctl mutex_lock(&nbd->config_lock) // get lock __nbd_ioctl nbd_add_socket krealloc kfree(p) //config->socks is NULL nbd_sock *nsock = config->socks // error Fix it by moving config_lock up before sock_shutdown. Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit b3e3e34c)
-
由 Li Lingfeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I79ZEK CVE: NA -------------------------------- As described in commit d0dcee7d ("dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata"), ABBA deadlock will be triggered since shrinker_rwsem need to be held when operations failed on dm pool metadata. We have noticed the following three problem scenarios: 1) Described by commit d0dcee7d ("dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata") 2) shrinker_rwsem and throttle->lock P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_wait_block_bitmap __ext4_error ext4_handle_error ext4_commit_super ... dm_submit_bio do_worker throttle_work_update down_write(&t->lock) -- LOCK B process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata dm_block_manager_create dm_bufio_client_create register_shrinker down_write(&shrinker_rwsem) -- LOCK A thin_map thin_bio_map thin_defer_bio_with_throttle throttle_lock down_read(&t->lock) - LOCK B 3) shrinker_rwsem and wait_on_buffer P1(drop cache) P2(kworker) drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab ... ext4_wait_block_bitmap __ext4_error ext4_handle_error jbd2_journal_abort jbd2_journal_update_sb_errno jbd2_write_superblock submit_bh // LOCK B // RELEASE B do_worker throttle_work_update down_write(&t->lock) - LOCK B process_deferred_bios process_bio commit metadata_operation_failed dm_pool_abort_metadata dm_block_manager_create dm_bufio_client_create register_shrinker register_shrinker_prepared down_write(&shrinker_rwsem) - LOCK A bio_endio wait_on_buffer __wait_on_buffer Fix these by resetting dm_bufio_client without holding shrinker_rwsem. Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 890e730d)
-
由 Li Lingfeng 提交于
Offering: HULK hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I78SWJ CVE: NA ------------------------------- In dm_create(), alloc_dev() may trigger panic if alloc_dax() fail since del_gendisk() will be called with add_disk() wasn't called before. Call add_disk() before alloc_dax() to avoid it. Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 6601d443)
-
由 ZhaoLong Wang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6GS86 CVE: NA -------------------------------- When memory allocated by using the devm_kmalloc(). the matching release function should use the devm_kfree() function instead of the kfree() function. @sreg allocated: hi6421_spmi_regulator_probe hi6421_spmi_regulator_probe_ldo @sreg freed: hi6421_spmi_regulator_remove Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> (cherry picked from commit 8a31aa41)
-
由 ZhaoLong Wang 提交于
maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6K5OH CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f773f0a331d6c41733b17bebbc1b6cae12e016f5 -------------------------------- During the processing of the bgt, if the sync_erase() return -EBUSY or some other error code in __erase_worker(),schedule_erase() called again lead to the down_read(ubi->work_sem) hold twice and may get block by down_write(ubi->work_sem) in ubi_update_fastmap(), which cause deadlock. ubi bgt other task do_work down_read(&ubi->work_sem) ubi_update_fastmap erase_worker # Blocked by down_read __erase_worker down_write(&ubi->work_sem) schedule_erase schedule_ubi_work down_read(&ubi->work_sem) Fix this by changing input parameter @nested of the schedule_erase() to 'true' to avoid recursively acquiring the down_read(&ubi->work_sem). Also, fix the incorrect comment about @nested parameter of the schedule_erase() because when down_write(ubi->work_sem) is held, the @nested is also need be true. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217093 Fixes: 2e8f08de ("ubi: Fix races around ubi_refill_pools()") Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 9d8256f3)
-
由 Lee Jones 提交于
mainline inclusion from mainline-v5.11-rc1 commit ab4e4de9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6K5OH CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab4e4de9fd8b469823a645f05f2c142e9270b012 -------------------------------- Fixes the following W=1 kernel build warning(s): drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not described in 'schedule_erase' drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown' description in '__erase_worker' Cc: Richard Weinberger <richard@nod.at> Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: linux-mtd@lists.infradead.org Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-13-lee.jones@linaro.orgSigned-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 9fea0e12)
-
- 03 6月, 2023 9 次提交
-
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188535, https://gitee.com/openeuler/kernel/issues/I6O61Q CVE: NA -------------------------------- Recovery will go to giveup and let chunks_skipped++ in raid10_sync_request if there are some bad_blocks, and it will return max_sector when chunks_skipped >= geo.raid_disks. Now, recovery fail and data is inconsistent but user think recovery is done, it is wrong. Fix it by set mirror's recovery_disabled and spare device shouln't be added to here. Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit b0ac58c9)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188378, https://gitee.com/openeuler/kernel/issues/I6GGV7 CVE: NA -------------------------------- init_resync() init mempool and set conf->have_replacemnt at the begaining of sync, close_sync() free the mempool when sync is completed. After commit 7e83ccbe ("md/raid10: Allow skipping recovery when clean arrays are assembled"), recovery might skipped and init_resync() is called but close_sync() is not. null-ptr-deref occurs as below: 1) creat a array, wait for resync to complete, mddev->recovery_cp is set to MaxSector. 2) recovery is woken and it is skipped. conf->have_replacement is set to 0 in init_resync(). close_sync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->have_replacemnt is 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref occurs. Fix it by not init_resync() if recovery skipped. Fixes: 7e83ccbe md/raid10: Allow skipping recovery when clean arrays are assembled") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 2de30b8f)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6XBZQ CVE: NA -------------------------------- If we set any badblocks fail, we will remove this rdev(set it to Faulty or set recovery_disabled). Previous patch "md/raid10: fix io hung in md_wait_for_blocked_rdev()" check badblocks->changed instead of return value in rdev_set_badblocks(), but return value of this func also changed accordingly, which is not what we expected. Keep the return value consistent with before. Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit bebf3d97)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6XBZQ CVE: NA -------------------------------- If badblocks are merged but bb->count exceedded, badblocks_set() will return 1 and merged badblocks will become un-ack. rdev_set_badblocks() will not set sb_flags and wakeup mddev->thread, io wait in md_wait_for_blocked_rdev() will hung because BlockedBadBlocks may not be cleared. Fix it by checking badblocks->changed instead of return value. This flag is set when badblocks changes. Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit c23e1cd1)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188605, https://gitee.com/openeuler/kernel/issues/I6ZJ3T CVE: NA -------------------------------- We get rdev from mirrors.replacement twice in raid10_write_request(). If replacement changes between two reads, it will increase A->nr_pending and decrease B->nr_pending. T1 (write) T2 (remove) T3 (add) raid10_remove_disk raid10_write_request rrdev = conf->mirrors[d].replacement; ->rdev A A nr_pending++ p->rdev = p->replacement; ->rdev A p->replacement = NULL; //A it set to WantReplacement raid10_add_disk p->replacement = rdev; ->rdev B if blocked_rdev rdev = conf->mirrors[d].replacement; ->rdev B B nr_pending-- We will record rdev in r10bio, and get rdev from r10bio to fix it. Fixes: 475b0321 ("md/raid10: writes should get directed to replacement as well as original.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 7b3b8187)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188605, https://gitee.com/openeuler/kernel/issues/I6GOYF CVE: NA -------------------------------- It might read mirror.redev first and then mirror->replacement because of memory reordering in raid10_end_write_request(), WARN_ON occurs if we remove disk at the same time. T1 remove T2 io end raid10_remove_disk raid10_end_write_request p->rdev = NULL read rdev -> NULL smp_mb p->replacement = NULL read replacement -> NULL It is meaningless to compare rdev with mirror->rdev after we get it from r10_bio in raid10_end_write_request(). Remove this WANR_ON_ONCE. Fixes: 2ecf5e6ecbfd ("md/raid10: fix uaf if replacement replaces rdev") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit a3ebeed7)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188377, https://gitee.com/openeuler/kernel/issues/I6GOYF CVE: NA -------------------------------- After commit 4ca40c2c ("md/raid10: Allow replacement device to be replace old drive.") mirrors->replacement can replace rdev during replacement's io pending, and repl_bio will write rdev (see raid10_write_one_disk()). We will get wrong device by r10conf in raid10_end_write_request(). In which case, r10_bio->devs[slot].repl_bio will be put but not set to IO_MADE_GOOD, and it will be put again later in raid_end_bio_io(), uaf occurs. Fix it by using r10_bio to record rdev. Put the operations of io fail and no replacement together, so no need to change repl. ================================================================== BUG: KASAN: use-after-free in bio_flagged include/linux/bio.h:238 [inline] BUG: KASAN: use-after-free in bio_put+0x78/0x80 block/bio.c:650 Read of size 2 at addr ffff888116524dd4 by task md0_raid10/2618 CPU: 0 PID: 2618 Comm: md0_raid10 Not tainted 5.10.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 sd 0:0:0:0: rejecting I/O to offline device Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:118 print_address_description.constprop.0+0x1c/0x270 mm/kasan/report.c:390 __kasan_report mm/kasan/report.c:550 [inline] kasan_report.cold+0x22/0x3a mm/kasan/report.c:567 bio_flagged include/linux/bio.h:238 [inline] bio_put+0x78/0x80 block/bio.c:650 put_all_bios drivers/md/raid10.c:248 [inline] free_r10bio drivers/md/raid10.c:257 [inline] raid_end_bio_io+0x3b5/0x590 drivers/md/raid10.c:309 handle_write_completed drivers/md/raid10.c:2699 [inline] raid10d+0x2f85/0x5af0 drivers/md/raid10.c:2759 md_thread+0x444/0x4b0 drivers/md/md.c:7932 kthread+0x38c/0x470 kernel/kthread.c:313 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299 Allocated by task 1400: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] set_alloc_info mm/kasan/common.c:498 [inline] __kasan_kmalloc.constprop.0+0xb5/0xe0 mm/kasan/common.c:530 slab_post_alloc_hook mm/slab.h:512 [inline] slab_alloc_node mm/slub.c:2923 [inline] slab_alloc mm/slub.c:2931 [inline] kmem_cache_alloc+0x144/0x360 mm/slub.c:2936 mempool_alloc+0x146/0x360 mm/mempool.c:391 bio_alloc_bioset+0x375/0x610 block/bio.c:486 bio_clone_fast+0x20/0x50 block/bio.c:711 raid10_write_one_disk+0x166/0xd30 drivers/md/raid10.c:1240 raid10_write_request+0x1600/0x2c90 drivers/md/raid10.c:1484 __make_request drivers/md/raid10.c:1508 [inline] raid10_make_request+0x376/0x620 drivers/md/raid10.c:1537 md_handle_request+0x699/0x970 drivers/md/md.c:451 md_submit_bio+0x204/0x400 drivers/md/md.c:489 __submit_bio block/blk-core.c:959 [inline] __submit_bio_noacct block/blk-core.c:1007 [inline] submit_bio_noacct+0x2e3/0xcf0 block/blk-core.c:1086 submit_bio+0x1a0/0x3a0 block/blk-core.c:1146 submit_bh_wbc+0x685/0x8e0 fs/buffer.c:3053 ext4_commit_super+0x37e/0x6c0 fs/ext4/super.c:5696 flush_stashed_error_work+0x28b/0x400 fs/ext4/super.c:791 process_one_work+0x9a6/0x1590 kernel/workqueue.c:2280 worker_thread+0x61d/0x1310 kernel/workqueue.c:2426 kthread+0x38c/0x470 kernel/kthread.c:313 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299 Freed by task 2618: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:361 __kasan_slab_free+0x151/0x180 mm/kasan/common.c:482 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook+0xa9/0x180 mm/slub.c:1608 slab_free mm/slub.c:3179 [inline] kmem_cache_free+0xcd/0x3d0 mm/slub.c:3196 mempool_free+0xe3/0x3b0 mm/mempool.c:500 bio_free+0xe2/0x140 block/bio.c:266 bio_put+0x58/0x80 block/bio.c:651 raid10_end_write_request+0x885/0xb60 drivers/md/raid10.c:516 bio_endio+0x376/0x6a0 block/bio.c:1465 req_bio_endio block/blk-core.c:289 [inline] blk_update_request+0x5f5/0xf40 block/blk-core.c:1525 blk_mq_end_request+0x4c/0x510 block/blk-mq.c:654 blk_flush_complete_seq+0x835/0xd80 block/blk-flush.c:204 flush_end_io+0x7b7/0xb90 block/blk-flush.c:261 __blk_mq_end_request+0x282/0x4c0 block/blk-mq.c:645 scsi_end_request+0x3a8/0x850 drivers/scsi/scsi_lib.c:607 scsi_io_completion+0x3f5/0x1320 drivers/scsi/scsi_lib.c:970 scsi_softirq_done+0x11b/0x490 drivers/scsi/scsi_lib.c:1448 blk_mq_complete_request block/blk-mq.c:788 [inline] blk_mq_complete_request+0x84/0xb0 block/blk-mq.c:785 scsi_mq_done+0x155/0x360 drivers/scsi/scsi_lib.c:1603 virtscsi_vq_done drivers/scsi/virtio_scsi.c:184 [inline] virtscsi_req_done+0x14c/0x220 drivers/scsi/virtio_scsi.c:199 vring_interrupt drivers/virtio/virtio_ring.c:2061 [inline] vring_interrupt+0x27a/0x300 drivers/virtio/virtio_ring.c:2047 __handle_irq_event_percpu+0x2f8/0x830 kernel/irq/handle.c:156 handle_irq_event_percpu kernel/irq/handle.c:196 [inline] handle_irq_event+0x105/0x280 kernel/irq/handle.c:213 handle_edge_irq+0x258/0xd20 kernel/irq/chip.c:828 asm_call_irq_on_stack+0xf/0x20 __run_irq_on_irqstack arch/x86/include/asm/irq_stack.h:48 [inline] run_irq_on_irqstack_cond arch/x86/include/asm/irq_stack.h:101 [inline] handle_irq arch/x86/kernel/irq.c:230 [inline] __common_interrupt arch/x86/kernel/irq.c:249 [inline] common_interrupt+0xe2/0x190 arch/x86/kernel/irq.c:239 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:626 Fixes: 4ca40c2c ("md/raid10: Allow replacement device to be replace old drive.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit af959500)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188527, https://gitee.com/openeuler/kernel/issues/I6O3HO CVE: NA -------------------------------- need_replace will be set to 1 if no-Faulty mreplace exists, and mreplace will be deref later. However, the latter check of mreplace might set mreplace to NULL, null-ptr-deref occurs if need_replace is 1 at this time. Fix it by merging two checks into one. Fixes: ee37d731 ("md/raid10: Fix raid10 replace hang when new added disk faulty") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit 7718714e)
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188787, https://gitee.com/openeuler/kernel/issues/I78YIW CVE: NA -------------------------------- When we remove a disk which has replacement, first set rdev to NULL and then set replacement to rdev, finally set replacement to NULL (see raid10_remove_disk()). If io is submitted during the same time, it might read both rdev and replacement as NULL, and io will not be submitted. rdev -> NULL read rdev replacement -> NULL read replacement Fix it by reading replacement first and rdev later, meanwhile, use smp_mb() to prevent memory reordering. Fixes: 475b0321 ("md/raid10: writes should get directed to replacement as well as original.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> (cherry picked from commit e8025850)
-