- Oct 10, 2022
-
-
Jan Kara authoredmainline inclusion from mainline-v6.1-rc1 commit 61a1d87a324ad5e3ed27c6699dfc93218fcf3201 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I58WSQ CVE: CVE-2022-1184 -------------------------------- The check in __ext4_read_dirblock() for block being outside of directory size was wrong because it compared block number against directory size in bytes. Fix it. Fixes: 65f8ea4cd57d ("ext4: check if directory block is within i_size") CVE: CVE-2022-1184 CC: stable@vger.kernel.org Signed-off-by:
Jan Kara <jack@suse.cz>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Link: https://lore.kernel.org/r/20220822114832.1482-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Lukas Czerner authored
mainline inclusion from mainline-v6.0-rc1 commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I58WSQ CVE: CVE-2022-1184 -------------------------------- Currently ext4 directory handling code implicitly assumes that the directory blocks are always within the i_size. In fact ext4_append() will attempt to allocate next directory block based solely on i_size and the i_size is then appropriately increased after a successful allocation. However, for this to work it requires i_size to be correct. If, for any reason, the directory inode i_size is corrupted in a way that the directory tree refers to a valid directory block past i_size, we could end up corrupting parts of the directory tree structure by overwriting already used directory blocks when modifying the directory. Fix it by catching the corruption early in __ext4_read_dirblock(). Addresses Red-Hat-Bugzilla: #2070205 CVE: CVE-2022-1184...
-
- Oct 09, 2022
-
-
Luo Meng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5TY3L CVE: NA -------------------------------- A crash as follows: BUG: unable to handle page fault for address: 000000011241cec7 sd 5:0:0:1: [sdl] Synchronizing SCSI cache #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2465367 Comm: multipath Kdump: loaded Tainted: G W O 5.10.0-60.18.0.50.h478.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220525_182517-szxrtosci10000 04/01/2014 RIP: 0010:kernfs_new_node+0x22/0x60 Code: cc cc 66 0f 1f 44 00 00 0f 1f 44 00 00 41 54 41 89 cb 0f b7 ca 48 89 f2 53 48 8b 47 08 48 89 fb 48 89 de 48 85 c0 48 0f 44 c7 <48> 8b 78 50 41 51 45 89 c1 45 89 d8 e8 4d ee ff ff 5a 49 89 c4 48 RSP: 0018:ffffa178419539e8 EFLAGS: 00010206 RAX: 000000011241ce77 RBX: ffff9596828395a0 RCX: 000000000000a1ff RDX: ffff9595ada828b0 RSI: ffff9596828395a0 RDI: ffff9596828395a0 RBP: ffff95959a9a2a80 R08: 0000000000000000 R09: 0000000000000004 R10: ffff9595ca0bf930 R11: 0000000000000000 R12: ffff9595ada828b0 R13: ffff9596828395a0 R14: 0000000000000001 R15: ffff9595948c5c80 FS: 00007f64baa10200(0000) GS:ffff9596bad80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000011241cec7 CR3: 000000011923e003 CR4: 0000000000170ee0 Call Trace: kernfs_create_link+0x31/0xa0 sysfs_do_create_link_sd+0x61/0xc0 bd_link_disk_holder+0x10a/0x180 dm_get_table_device+0x10b/0x1f0 [dm_mod] __dm_get_device+0x1e2/0x280 [dm_mod] ? kmem_cache_alloc_trace+0x2fb/0x410 parse_path+0xca/0x200 [dm_multipath] parse_priority_group+0x19d/0x1f0 [dm_multipath] multipath_ctr+0x27a/0x491 [dm_multipath] dm_table_add_target+0x177/0x360 [dm_mod] table_load+0x12b/0x380 [dm_mod] ctl_ioctl+0x199/0x290 [dm_mod] ? dev_suspend+0xd0/0xd0 [dm_mod] dm_ctl_ioctl+0xa/0x20 [dm_mod] __se_sys_ioctl+0x85/0xc0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 This can be easy reproduce: Add delay before ret = add_symlink(bdev->bd_part->holder_dir...) in bd_link_disk_holder() dmsetup create xxx --tabel "0 1000 linear /dev/sda 0" echo 1 > /sys/block/sda/device/delete Delete /dev/sda will release holder_dir, but add_symlink() will use holder_dir. Therefore UAF will occur in this case. Fix this problem by adding reference count to holder_dir. Signed-off-by:
Luo Meng <luomeng12@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Sasha Levin authored
stable inclusion from stable-v5.4.215 commit 4051324a6dafd7053c74c475e80b3ba10ae672b0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5T9C3 CVE: CVE-2022-3303 --------------------------- [ Upstream commit 8423f0b6d513b259fdab9c9bf4aaa6188d054c2d ] There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant. Reported-and-tested-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https:... -
余快 authored
hulk inclusion category: performance bugzilla: 187597, https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- If CONFIG_BLK_BIO_DISPATCH_ASYNC is enabled, and driver support QUEUE_FLAG_DISPATCH_ASYNC, bios will be dispatched asynchronously to specific CPUs to avoid across nodes memory access in driver. 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: performance bugzilla: 187597, https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- request_queue_wrapper is not accessible in drivers currently, introduce a new helper to initialize async dispatch to fix kabi broken. 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: performance bugzilla: 187597, https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- Try to improve performance for raid when user issues io concurrently from multiple nodes. Signed-off-by:
Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Wang ShaoBo authored
hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- For some architectures, masking the underlying processor topology differences can make software unable to identify the cpu distance, which results in performance fluctuations. So we provide additional interface for getting preferred sibling's cpumask supported by platform, this siblings' cpumask indicates those CPUs which are clustered with relatively short distances, but this hardly depends on the specific implementation of the specific platform. Signed-off-by:
Wang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
余快 authored
hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- In some architecture memory access latency is very bad across nodes compare to local node. For consequence, io performance is rather bad while users issue io from multiple nodes if lock contention exist in the driver. This patch make io dispatch asynchronously to specific kthread that is bind to cpus that are belong to the same node, so that memory access across nodes in driver can be avoided. 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: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I5QK5M CVE: NA -------------------------------- Add a new flag QUEUE_FLAG_DISPATCH_ASYNC and two new fields 'dispatch_cpumask' and 'last_dispatch_cpu' for request_queue, prepare to support dispatch bio asynchronous in specified cpus. This patch also add sysfs apis. 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 md-next commit ddc489e066cd267b383c0eed4f576f6bdb154588 category: performance bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5PRMO CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit/?h=md-next&id=ddc489e066cd267b383c0eed4f576f6bdb154588 --------------------- Currently, wait_barrier() will hold 'resync_lock' to read 'conf->barrier', and io can't be dispatched until 'barrier' is dropped. Since holding the 'barrier' is not common, convert 'resync_lock' to use seqlock so that holding lock can be avoided in fast path. Signed-off-by:
Yu Kuai <yukuai3@huawei.com>
Reviewed-and-tested-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Song Liu <song@kernel.org>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
余快 authored
mainline inclusion from md-next commit 7fdc91928ac109d3d1468ad7f951deb29a375e3d category: performance bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5PRMO CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit/?h=md-next&id=7fdc91928ac109d3d1468ad7f951deb29a375e3d -------------------------------- Currently, wake_up() is called unconditionally in fast path such as raid10_make_request(), which will cause lock contention under high concurrency: raid10_make_request wake_up __wake_up_common_lock spin_lock_irqsave Improve performance by only call wake_up() if waitqueue is not empty. Signed-off-by:
Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev>
Signed-off-by: Song Liu <song@kernel.org>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
openeuler-ci-bot authored
Merge Pull Request from: @tangbinzy This PR is to adapt the 4.19 kernel to the openEuler 22.03 system, the step one is just for initial kernel use. Kernel Issue: 1）the problems of 4.19 kernel on openEuler 22.03 system, as follows: https://gitee.com/openeuler/kernel/issues/I5Q0UG 2）the common problems of 4.19 kernel on 22.03/20.03, as follows: 2.1、https://gitee.com/openeuler/kernel/issues/I5QR5E 2.2、https://gitee.com/openeuler/kernel/issues/I5QSAP 2.3、https://gitee.com/openeuler/kernel/issues/I5RTF5 2.4、https://gitee.com/openeuler/kernel/issues/I5RZPX Default config change N/A Link:https://gitee.com/openeuler/kernel/pulls/122 Reviewed-by:
Jackie Liu <liuyun01@kylinos.cn>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- Sep 29, 2022
-
-
Guo Mengqi authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5R0X9 CVE: NA -------------------------------- Fix a AA deadlock caused by nested lock in mg_sp_group_add_task(). Deadlock path: mg_sp_group_add_task() down_write(sp_group_sem) find_or_alloc_sp_group() !spg_valid() sp_group_drop() free_sp_group() -> down_write(sp_group_sem) ---> AA deadlock Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Guo Mengqi authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5QQPG CVE: NA -------------------------------- Add a size-0-check in mg_sp_make_share_k2u() to avoid passing 0-size spa to __insert_sp_area(). Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Guo Mengqi authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5QETC CVE: NA -------------------------------- sp_make_share_k2u only supports vmalloc address now. Therefore, delete a backup handle case. Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Luo Meng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5TMYD CVE: NA -------------------------------- This reverts commit 7959a470. Commit 2fe0e281f7ad (cifs: fix double free race when mount fails in cifs_get_root()) fixes a double free. However there is no such issue on 4.19 because it will return after cifs_cleanup_volume_info(). Since merge this patch, cifs_cleanup_volume_info() is skipped, leading to a memory leak. Signed-off-by:
Luo Meng <luomeng12@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
-
- Sep 28, 2022
-
-
Xingui Yang authored
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SXSB CVE: NA ------------------------------------------------ When the port is detached, EH will clear ATA_EH_RESET in ehc->i.action when call ata_eh_reset(), and device reset won't be executed. As the disk won't return other I/Os normally after NCQ Error. In addition, the abort operation is added, then resource release is safe, so release NCQ command lldd resource directly in hisi_sas_abort_task() when NCQ error without soft reset to make sure read log command can be executed success later. But Soft reset still need to be used in other scenario. Signed-off-by:
Xingui Yang <yangxingui@huawei.com>
Reviewed-by: kang fenglong <kangfenglong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Xingui Yang authored
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5QDH7 CVE: NA ---------------------------------- the SAS controller determines the disk to which I/Os are delivered based on the port id in the DQ entry when SATA disk directly connected. When the link is intermittently disconnected during I/O sending and the port id changes and is used by another link, data inconsistency on the SATA disk may occur during I/O retry. So enable force phy, then force the command to be executed in a certain phy, and if the port's phy does not match the phy configured in the command, the chip will stop delivering I/Os to disk. Signed-off-by:
Xingui Yang <yangxingui@huawei.com>
Reviewed-by: kang fenglong <kangfenglong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Xingui Yang authored
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q63H CVE: NA ------------------------------------- When an NCQ error occurs, SAS controller will abnormally complete the I/Os that newly delivered to disk, and bit8 in CQ dw3 will be set to 1 to indicate current SATA disk is in error status. The current processing flow is set ts->stat to SAS_OPEN_REJECT and then sas_ata_task_done() will set fis stat to ATA_ERR. After analyzed by ata_eh_analyze_tf(), err_mask will set to AC_ERR_HSM. If media error occurs for four times within 10 minutes and the chip rejects new I/Os for four times, NCQ will be disabled due to excessive errors. However, if media error occurs multiple times, the NCQ mode shouldn't be disabled. Therefore, use sas_task_abort() to handle abnormally completed I/Os when SATA disk is in error status. [10253.397429] hisi_sas_v3_hw 0000:b4:02.0: erroneous completion disk err dev id=2 sas_addr=0x5000000000000605 CQ hdr: 0x400903 0x2007f 0x0 0x80470000 [10253.397430] hisi_sas_v3_hw 0000:b4:02.0: erroneous completion iptt=135 task= pK-error dev id=2 sas_addr=0x5000000000000605 CQ hdr: 0x203 0x20087 0x0 0x100 Error info: 0x0 0x0 0x0 0x0 [10253.397432] hisi_sas_v3_hw 0000:b4:02.0: erroneous completion iptt=136 task= pK-error dev id=2 sas_addr=0x5000000000000605 CQ hdr: 0x203 0x20088 0x0 0x100 Error info: 0x0 0x0 0x0 0x0 Signed-off-by:
Xingui Yang <yangxingui@huawei.com>
Reviewed-by: kang fenglong <kangfenglong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Hui Tang authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5TIOZ CVE: NA -------------------------------- BUG: KASAN: double-free or invalid-free in sched_prefer_cpus_free[...] Freed by task 0: save_stack mm/kasan/kasan.c:448 [inline] set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x120/0x228 mm/kasan/kasan.c:521 kasan_slab_free+0x10/0x18 mm/kasan/kasan.c:528 slab_free_hook mm/slub.c:1397 [inline] slab_free_freelist_hook mm/slub.c:1425 [inline] slab_free mm/slub.c:3004 [inline] kfree+0x84/0x250 mm/slub.c:3965 sched_prefer_cpus_free+0x58/0x78 kernel/sched/core.c:7219 free_task+0xb0/0xe8 kernel/fork.c:463 __delayed_free_task+0x24/0x30 kernel/fork.c:1716 __rcu_reclaim kernel/rcu/rcu.h:236 [inline] rcu_do_batch+0x200/0x5e0 kernel/rcu/tree.c:2584 invoke_rcu_callbacks kernel/rcu/tree.c:2897 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2864 [inline] rcu_process_callbacks+0x470/0xb60 kernel/rcu/tree.c:...
-
John Donnelly authored
mainline inclusion from mainline-v5.10-rc1 commit 8c4e0f21 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SXLB CVE: NA -------------------------------- Corrects drivers/target/target_core_user.c:688:6: warning: 'page' may be used uninitialized. Link: https://lore.kernel.org/r/20200924001920.43594-1-john.p.donnelly@oracle.com Fixes: 3c58f737 ("scsi: target: tcmu: Optimize use of flush_dcache_page") Cc: Mike Christie <michael.christie@oracle.com> Acked-by:
Mike Christie <michael.christie@oracle.com>
Signed-off-by: John Donnelly <john.p.donnelly@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Reviewed-by: lijinlin <lijinlin3@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Bodo Stroesser authored
mainline inclusion from mainline-v5.9-rc1 commit 5a0c256d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SXLB CVE: NA -------------------------------- If tcmu_handle_completions() has to process a padding shorter than sizeof(struct tcmu_cmd_entry), the current call to tcmu_flush_dcache_range() with sizeof(struct tcmu_cmd_entry) as length param is wrong and causes crashes on e.g. ARM, because tcmu_flush_dcache_range() in this case calls flush_dcache_page(vmalloc_to_page(start)); with start being an invalid address above the end of the vmalloc'ed area. The fix is to use the minimum of remaining ring space and sizeof(struct tcmu_cmd_entry) as the length param. The patch was tested on kernel 4.19.118. See https://bugzilla.kernel.org/show_bug.cgi?id=208045#c10 Link: https://lore.kernel.org/r/20200629093756.8947-1-bstroesser@ts.fujitsu.com Tested-by:
JiangYu <lnsyyj@hotmail.com>
Acked-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Reviewed-by: lijinlin <lijinlin3@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Bodo Stroesser authored
mainline inclusion from mainline-v5.9-rc1 commit 3c58f737 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SXLB CVE: NA -------------------------------- (scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page()...
-
Bodo Stroesser authored
mainline inclusion from mainline-v5.8-rc1 commit 8c4e0f21 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SXLB CVE: NA -------------------------------- 1) If remaining ring space before the end of the ring is smaller then the next cmd to write, tcmu writes a padding entry which fills the remaining space at the end of the ring. Then tcmu calls tcmu_flush_dcache_range() with the size of struct tcmu_cmd_entry as data length to flush. If the space filled by the padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is called for an address range reaching behind the end of the vmalloc'ed ring. tcmu_flush_dcache_range() in a loop calls flush_dcache_page(virt_to_page(start)); for every page being part of the range. On x86 the line is optimized out by the compiler, as flush_dcache_page() is empty on x86. But I assume the above can cause trouble on other architectures that really have a flush_dcache_page(). For paddings only the header part of an entry is relevant due to alignment rules the header always fits in the remaining space, if padding is needed. So tcmu_flush_dcache_range() can safely be called with sizeof(entry->hdr) as the length here. 2) After it has written a command to cmd ring, tcmu calls tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as data length to flush. But if a command needs many iovecs, the real size of the command may be bigger then tcmu_cmd_entry, so a part of the written command is not flushed then. Link: https://lore.kernel.org/r/20200528193108.9085-1-bstroesser@ts.fujitsu.com Acked-by:
Mike Christie <michael.christie@oracle.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Reviewed-by: lijinlin <lijinlin3@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Ye Weihua authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5T8FD CVE: NA -------------------------------- __dend_signal_locked() invokes __sigqueue_alloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below (test in 5.10): CPU0 CPU1 ---- ---- lock(&sighand->siglock); lock(&tty->read_wait); lock(&sighand->siglock); lock(console_owner); This patch specities __GFP_NOWARN to __sigqueue_alloc(), so that printk will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.10.0-04424-ga472e3c833d3 #1 Not tainted ------------------------------------------------------ syz-executor.2/31970 is trying to acquire lock: ffffa00014066a60 (console_owner){-.-.}-{0:0}, at...
-
Qi Zheng authored
mainline inclusion from mainline-v5.19-rc1 commit 3f913fc5f9745613088d3c569778c9813ab9c129 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5T8FD CVE: NA -------------------------------- We expect no warnings to be issued when we specify __GFP_NOWARN, but currently in paths like alloc_pages() and kmalloc(), there are still some warnings printed, fix it. But for some warnings that report usage problems, we don't deal with them. If such warnings are printed, then we should fix the usage problems. Such as the following case: WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); [zhengqi.arch@bytedance.com: v2] Link: https://lkml.kernel.org/r/20220511061951.1114-1-zhengqi.arch@bytedance.com Link: https://lkml.kernel.org/r/20220510113809.80626-1-zhengqi.arch@bytedance.com Signed-off-by:
Qi Zheng <zhengqi.arch@bytedance.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfo...
-
- Sep 27, 2022
-
-
Like Xu authored
mainline inclusion from mainline-v5.18 commit 75189d1de1b377e580ebd2d2c55914631eac9c64 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SDUS CVE: NA ------------- NMI-watchdog is one of the favorite features of kernel developers, but it does not work in AMD guest even with vPMU enabled and worse, the system misrepresents this capability via /proc. This is a PMC emulation error. KVM does not pass the latest valid value to perf_event in time when guest NMI-watchdog is running, thus the perf_event corresponding to the watchdog counter will enter the old state at some point after the first guest NMI injection, forcing the hardware register PMC0 to be constantly written to 0x800000000001. Meanwhile, the running counter should accurately reflect its new value based on the latest coordinated pmc->counter (from vPMC's point of view) rather than the value written directly by the guest. Fixes: 168d918f ("KVM: x86: Adjust counter sample period after a wrmsr") Reported-by:
Dongli Cao <caodongli@kingsoft.com>
Signed-off-by: Like Xu <likexu@tencent.com>
Reviewed-by: Yanan Wang <wangyanan55@huawei.com>
Tested-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Message-Id: <20220409015226.38619-1-likexu@tencent.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
[Yanan Wang: Adapt the code to linux v4.19]
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com> -
Eric Hankland authored
mainline inclusion from mainline-v5.6 commit 168d918f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SDUS CVE: NA ------------- The sample_period of a counter tracks when that counter will overflow and set global status/trigger a PMI. However this currently only gets set when the initial counter is created or when a counter is resumed; this updates the sample period after a wrmsr so running counters will accurately reflect their new value. Signed-off-by:
Eric Hankland <ehankland@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
[Yanan Wang: Adapt the code to linux v4.19]
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com> -
Eric Hankland authored
mainline inclusion from mainline-v5.5 commit 4400cf54 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SDUS CVE: NA ------------- Correct the logic in intel_pmu_set_msr() for fixed and general purpose counters. This was recently changed to set pmc->counter without taking in to account the value of pmc_read_counter() which will be incorrect if the counter is currently running and non-zero; this changes back to the old logic which accounted for the value of currently running counters. Signed-off-by:
Eric Hankland <ehankland@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com> -
Like Xu authored
mainline inclusion from mainline-v5.4 commit 3ca270fc category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5SDUS CVE: NA ------------- Currently, perf_event_period() is used by user tools via ioctl. Based on naming convention, exporting perf_event_period() for kernel users (such as KVM) who may recalibrate the event period for their assigned counter according to their requirements. The perf_event_period() is an external accessor, just like the perf_event_{en,dis}able() and should thus use perf_event_ctx_lock(). Suggested-by:
Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yanan Wang <wangyanan55@huawei.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com> -
Dongliang Mu authored
stable inclusion from stable-v4.19.238 commit 0113fa98a49a8e46a19b0ad80f29c904c6feec23 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5RX5X CVE: CVE-2022-3239 --------------------------- [ Upstream commit c08eadca1bdfa099e20a32f8fa4b52b2f672236d ] The commit 47677e51("[media] em28xx: Only deallocate struct em28xx after finishing all extensions") adds kref_get to many init functions (e.g., em28xx_audio_init). However, kref_init is called too late in em28xx_usb_probe, since em28xx_init_dev before will invoke those init functions and call kref_get function. Then refcount bug occurs in my local syzkaller instance. Fix it by moving kref_init before em28xx_init_dev. This issue occurs not only in dev but also dev->dev_next. Fixes: 47677e51 ("[media] em28xx: Only deallocate struct em28xx after finishing all extensions") Reported-by:
syzkaller <syzkaller@googlegroups.com>
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.co...>
-
- Sep 26, 2022
-
-
Li Lingfeng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SR8X CVE: NA -------------------------------- ====================================================== WARNING: possible circular locking dependency detected 4.18.0+ #4 Tainted: G ---------r- - ------------------------------------------------------ dmsetup/923 is trying to acquire lock: 000000008d8170dd (kn->count#184){++++}, at: kernfs_remove+0x24/0x40 fs/kernfs/dir.c:1354 but task is already holding lock: 000000003377330b (slab_mutex){+.+.}, at: kmem_cache_destroy+0xec/0x320 mm/slab_common.c:928 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slab_mutex){+.+.}: __mutex_lock_common kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x11a0 kernel/locking/mutex.c:1072 slab_attr_store+0x6d/0xe0 mm/slub.c:5526 sysfs_kf_write+0x10f/0x170 fs/sysfs/file.c:139 kernfs_fop_write+0x290/0x440 fs/kernfs/file.c:316 __vfs_write+0x81/0x100 fs/read_write.c:485 vfs_write+0x184/0x4c0 fs/read_write.c:549 ksys_write+0xc6/0x1a0 fs/read_write.c:598 do_syscall_64+0xca/0x5a0 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf -> #0 (kn->count#184){++++}: lock_acquire+0x10f/0x340 kernel/locking/lockdep.c:3868 kernfs_drain fs/kernfs/dir.c:467 [inline] __kernfs_remove fs/kernfs/dir.c:1320 [inline] __kernfs_remove+0x6d0/0x890 fs/kernfs/dir.c:1279 kernfs_remove+0x24/0x40 fs/kernfs/dir.c:1354 sysfs_remove_dir+0xb6/0xf0 fs/sysfs/dir.c:99 kobject_del.part.1+0x35/0xe0 lib/kobject.c:573 kobject_del+0x1b/0x30 lib/kobject.c:569 shutdown_cache+0x17f/0x310 mm/slab_common.c:592 kmem_cache_destroy+0x263/0x320 mm/slab_common.c:943 bio_put_slab block/bio.c:152 [inline] bioset_exit+0x20d/0x330 block/bio.c:1916 cleanup_mapped_device+0x64/0x360 drivers/md/dm.c:1903 free_dev+0xbc/0x240 drivers/md/dm.c:2058 __dm_destroy+0x317/0x490 drivers/md/dm.c:2426 dm_hash_remove_all+0x8f/0x250 drivers/md/dm-ioctl.c:314 remove_all+0x4d/0x90 drivers/md/dm-ioctl.c:471 ctl_ioctl+0x426/0x910 drivers/md/dm-ioctl.c:1870 dm_ctl_ioctl+0x23/0x30 drivers/md/dm-ioctl.c:1892 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1a5/0x1100 fs/ioctl.c:696 ksys_ioctl+0x7c/0xa0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x74/0xb0 fs/ioctl.c:718 do_syscall_64+0xca/0x5a0 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slab_mutex); lock(kn->count#184); lock(slab_mutex); lock(kn->count#184); A potential deadlock may occur when we remove and write a slab-attr-file in /sys/kernfs/slab/xxx/ at the same time. The lock sequence in remove process is: slab_mutex --> kn->count The lock sequence in write process is: kn->count --> slab_mutex This can be fixed by replacing mutex_lock with mutex_trylock in slab_attr_store. Signed-off-by:
Li Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Baokun Li authored
hulk inclusion category: bugfix bugzilla: 187600, https://gitee.com/openeuler/kernel/issues/I5SV2U CVE: NA -------------------------------- If the starting position of our insert range happens to be in the hole between the two ext4_extent_idx, because the lblk of the ext4_extent in the previous ext4_extent_idx is always less than the start, which leads to the "extent" variable access across the boundary, the following UAF is triggered: ================================================================== BUG: KASAN: use-after-free in ext4_ext_shift_extents+0x257/0x790 Read of size 4 at addr ffff88819807a008 by task fallocate/8010 CPU: 3 PID: 8010 Comm: fallocate Tainted: G E 5.10.0+ #492 Call Trace: dump_stack+0x7d/0xa3 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x67/0x7f ext4_ext_shift_extents+0x257/0x790 ext4_insert_range+0x5b6/0x700 ext4_fallocate+0x39e/0x3d0 vfs_fallocate+0x26f/0x470 ksys_fallocate+0x3a/0...
-
Zhihao Cheng authored
hulk inclusion category: bugfix bugzilla: 187046, https://gitee.com/openeuler/kernel/issues/I5QH0X CVE: NA -------------------------------- It would be better to do more sanity checking (eg. dqdh_entries, block no.) for the content read from quota file, which can prevent corrupting the quota file. Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Zhihao Cheng authored
hulk inclusion category: bugfix bugzilla: 187046, https://gitee.com/openeuler/kernel/issues/I5QH0X CVE: NA -------------------------------- Cleanup all block checking places, replace them with helper function do_check_range(). Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Zhihao Cheng authored
hulk inclusion category: bugfix bugzilla: 187046, https://gitee.com/openeuler/kernel/issues/I5QH0X CVE: NA -------------------------------- Following process: Init: v2_read_file_info: <3> dqi_free_blk 0 dqi_free_entry 5 dqi_blks 6 Step 1. chown bin f_a -> dquot_acquire -> v2_write_dquot: qtree_write_dquot do_insert_tree find_free_dqentry get_free_dqblk write_blk(info->dqi_blocks) // info->dqi_blocks = 6, failure. The content in physical block (corresponding to blk 6) is random. Step 2. chown root f_a -> dquot_transfer -> dqput_all -> dqput -> ext4_release_dquot -> v2_release_dquot -> qtree_delete_dquot: dquot_release remove_tree free_dqentry put_free_dqblk(6) info->dqi_free_blk = blk // info->dqi_free_blk = 6 Step 3. drop cache (buffer head for block 6 is released) Step 4. chown bin f_b -> dquot_acquire -> commit_dqblk -> v2_write_dquot: qtree_write_dquot do_insert_tree find_free_dqentry get_free_dqblk dh = (struct qt_disk_dqdbheader *)buf blk = info->dqi_free_blk // 6 ret = read_blk(info, blk, buf) // The content of buf is random info->dqi_free_blk = le32_to_cpu(dh->dqdh_next_free) // random blk Step 5. chown bin f_c -> notify_change -> ext4_setattr -> dquot_transfer: dquot = dqget -> acquire_dquot -> ext4_acquire_dquot -> dquot_acquire -> commit_dqblk -> v2_write_dquot -> dq_insert_tree: do_insert_tree find_free_dqentry get_free_dqblk blk = info->dqi_free_blk // If blk < 0 and blk is not an error code, it will be returned as dquot transfer_to[USRQUOTA] = dquot // A random negative value __dquot_transfer(transfer_to) dquot_add_inodes(transfer_to[cnt]) spin_lock(&dquot->dq_dqb_lock) // page fault , which will lead to kernel page fault: Quota error (device sda): qtree_write_dquot: Error -8000 occurred while creating quota BUG: unable to handle page fault for address: ffffffffffffe120 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 5974 Comm: chown Not tainted 6.0.0-rc1-00004 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:_raw_spin_lock+0x3a/0x90 Call Trace: dquot_add_inodes+0x28/0x270 __dquot_transfer+0x377/0x840 dquot_transfer+0xde/0x540 ext4_setattr+0x405/0x14d0 notify_change+0x68e/0x9f0 chown_common+0x300/0x430 __x64_sys_fchownat+0x29/0x40 In order to avoid accessing invalid quota memory address, this patch adds block number checking of next/prev free block read from quota file. Fetch a reproducer in [Link]. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216372 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Hyunwoo Kim authored
mainline inclusion from mainline-v6.0-rc5 commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5QI0W CVE: CVE-2022-40307 --------------------------- A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by:
Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Xia Longlong <xialonglong1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiu Jianfeng <x... -
Lu Wei authored
mainline inclusion from mainline-v6.0-rc6 commit 81225b2ea161af48e093f58e8dfee6d705b16af4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5SYBY CVE: NA -------------------------------- If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug. Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by:
Lu Wei <luwei32@huawei.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> -
Wang Wensheng authored
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PD4P CVE: NA -------------------------------- [ 2058.802818][ T290] BUG: KASAN: use-after-free in get_process_sp_res+0x70/0x134 [ 2058.810194][ T290] Read of size 8 at addr ffff00088dc6ab28 by task test_debug_loop/290 [ 2058.820520][ T290] CPU: 5 PID: 290 Comm: test_debug_loop Tainted: G W OE 5.10.0+ #2 [ 2058.829377][ T290] Hardware name: EVB(EP) (DT) [ 2058.833982][ T290] Call trace: [ 2058.837217][ T290] dump_backtrace+0x0/0x30c [ 2058.841660][ T290] show_stack+0x20/0x30 [ 2058.845758][ T290] dump_stack+0x120/0x1b0 [ 2058.850028][ T290] print_address_description.constprop.0+0x2c/0x1fc [ 2058.856555][ T290] __kasan_report+0xfc/0x160 [ 2058.861086][ T290] kasan_report+0x44/0xb0 [ 2058.865356][ T290] __asan_load8+0x94/0xd0 [ 2058.869623][ T290] get_process_sp_res+0x70/0x134 [ 2058.874501][ T290] proc_usage_show+0x1ac/0x304 [ 2058.879208][ T290] seq_read_iter+0x254/0x750 [ 2058.883728][ T290] proc_reg_read_iter+0x100/0x140 [ 2058.888689][ T290] new_sync_read+0x1cc/0x2c0 [ 2058.893215][ T290] vfs_read+0x1f4/0x250 [ 2058.897304][ T290] ksys_read+0xcc/0x170 [ 2058.901399][ T290] __arm64_sys_read+0x4c/0x60 [ 2058.906016][ T290] el0_svc_common.constprop.0+0xb4/0x2a0 [ 2058.911584][ T290] do_el0_svc+0x8c/0xb0 [ 2058.915677][ T290] el0_svc+0x20/0x30 [ 2058.919503][ T290] el0_sync_handler+0xb0/0xbc [ 2058.924114][ T290] el0_sync+0x180/0x1c0 [ 2058.928190][ T290] [ 2058.930444][ T290] Allocated by task 2176: [ 2058.934714][ T290] kasan_save_stack+0x28/0x60 [ 2058.939328][ T290] __kasan_kmalloc.constprop.0+0xc8/0xf0 [ 2058.944909][ T290] kasan_kmalloc+0x10/0x20 [ 2058.949268][ T290] kmem_cache_alloc_trace+0x128/0xabc [ 2058.954577][ T290] create_spg_node+0x58/0x214 [ 2058.959188][ T290] local_group_add_task+0x30/0x14c [ 2058.964231][ T290] init_local_group+0xd0/0x1a0 [ 2058.968936][ T290] sp_init_group_master_locked.part.0+0x19c/0x290 [ 2058.975298][ T290] mg_sp_group_add_task+0x73c/0xdb0 [ 2058.980456][ T290] dev_sp_add_group+0x124/0x2dc [sharepool_dev] [ 2058.986647][ T290] dev_ioctl+0x21c/0x2ec [sharepool_dev] [ 2058.992222][ T290] __arm64_sys_ioctl+0xd8/0x120 [ 2058.997010][ T290] el0_svc_common.constprop.0+0xb4/0x2a0 [ 2059.002572][ T290] do_el0_svc+0x8c/0xb0 [ 2059.006662][ T290] el0_svc+0x20/0x30 [ 2059.010489][ T290] el0_sync_handler+0xb0/0xbc [ 2059.015101][ T290] el0_sync+0x180/0x1c0 [ 2059.019176][ T290] [ 2059.021427][ T290] Freed by task 4125: [ 2059.025343][ T290] kasan_save_stack+0x28/0x60 [ 2059.029949][ T290] kasan_set_track+0x28/0x40 [ 2059.034476][ T290] kasan_set_free_info+0x24/0x50 [ 2059.039347][ T290] __kasan_slab_free+0x104/0x1ac [ 2059.044227][ T290] kasan_slab_free+0x14/0x20 [ 2059.048744][ T290] kfree+0x164/0xb94 [ 2059.052576][ T290] sp_group_post_exit+0xf0/0x980 [ 2059.057448][ T290] mmput.part.0+0xb4/0x220 [ 2059.061790][ T290] mmput+0x2c/0x40 [ 2059.065450][ T290] exit_mm+0x27c/0x3a0 [ 2059.069450][ T290] do_exit+0x2a0/0x790 [ 2059.073448][ T290] do_group_exit+0x64/0x100 [ 2059.077884][ T290] get_signal+0x1fc/0x9fc [ 2059.082144][ T290] do_signal+0x110/0x2cc [ 2059.086320][ T290] do_notify_resume+0x158/0x2b0 [ 2059.091108][ T290] work_pending+0xc/0x6d4 [ 2059.095358][ T290] Signed-off-by:
Wang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: Weilong Chen <chenweilong@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
-