- 28 7月, 2022 12 次提交
-
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: 187250, https://gitee.com/openeuler/kernel/issues/I5HSMS CVE: NA ------------------------------------------------- Following process: vfs_setxattr(host) ubifs_xattr_set down_write(host_ui->xattr_sem) <- lock first time create_xattr ubifs_new_inode(host) fscrypt_prepare_new_inode(host) fscrypt_policy_to_inherit(host) if (IS_ENCRYPTED(inode)) fscrypt_require_key(host) fscrypt_get_encryption_info(host) ubifs_xattr_get(host) down_read(host_ui->xattr_sem) <- AA deadlock , which may trigger an AA deadlock problem: [ 102.620871] INFO: task setfattr:1599 blocked for more than 10 seconds. [ 102.625298] Not tainted 5.19.0-rc7-00001-gb666b6823ce0-dirty #711 [ 102.628732] task:setfattr state:D stack: 0 pid: 1599 [ 102.628749] Call Trace: [ 102.628753] <TASK> [ 102.628776] __schedule+0x482/0x1060 [ 102.629964] schedule+0x92/0x1a0 [ 102.629976] rwsem_down_read_slowpath+0x287/0x8c0 [ 102.629996] down_read+0x84/0x170 [ 102.630585] ubifs_xattr_get+0xd1/0x370 [ubifs] [ 102.630730] ubifs_crypt_get_context+0x1f/0x30 [ubifs] [ 102.630791] fscrypt_get_encryption_info+0x7d/0x1c0 [ 102.630810] fscrypt_policy_to_inherit+0x56/0xc0 [ 102.630817] fscrypt_prepare_new_inode+0x35/0x160 [ 102.630830] ubifs_new_inode+0xcc/0x4b0 [ubifs] [ 102.630873] ubifs_xattr_set+0x591/0x9f0 [ubifs] [ 102.630961] xattr_set+0x8c/0x3e0 [ubifs] [ 102.631003] __vfs_setxattr+0x71/0xc0 [ 102.631026] vfs_setxattr+0x105/0x270 [ 102.631034] do_setxattr+0x6d/0x110 [ 102.631041] setxattr+0xa0/0xd0 [ 102.631087] __x64_sys_setxattr+0x2f/0x40 Fetch a reproducer in [Link]. Just like ext4 does, which skips encrypting for inode with EXT4_EA_INODE_FL flag. Stop encypting xattr inode for ubifs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216260 Fixes: f4e3634a ("ubifs: Fix races between xattr_{set|get} ...") Fixes: d475a507 ("ubifs: Add skeleton for fscrypto") Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 ZhaoLong Wang 提交于
hulk inclusion category: bugfix bugzilla: 187163, https://gitee.com/openeuler/kernel/issues/I5GBC4 CVE: NA -------------------------------- The ubifs_compress() function does not compress the data When the data length is short than 128 bytes or the compressed data length is not ideal.It cause that the compressed length of the truncated data in the truncate_data_node() function may be greater than the length of the raw data read from the flash. The above two lengths are transferred to the ubifs_encrypt() function as parameters. This may lead to assertion fails and then the file system becomes read-only. This patch use the actual length of the data in the memory as the input parameter for assert comparison, which avoids the problem. Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: Nzhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Eric Snowberg 提交于
mainline inclusion from mainline-v5.19-rc8 commit 543ce63b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5I0FP CVE: CVE-2022-21505 Reference: https://seclists.org/oss-sec/2022/q3/57 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=543ce63b664e2c2f9533d089a4664b559c3e6b5b -------------------------------- The lockdown LSM is primarily used in conjunction with UEFI Secure Boot. This LSM may also be used on machines without UEFI. It can also be enabled when UEFI Secure Boot is disabled. One of lockdown's features is to prevent kexec from loading untrusted kernels. Lockdown can be enabled through a bootparam or after the kernel has booted through securityfs. If IMA appraisal is used with the "ima_appraise=log" boot param, lockdown can be defeated with kexec on any machine when Secure Boot is disabled or unavailable. IMA prevents setting "ima_appraise=log" from the boot param when Secure Boot is enabled, but this does not cover cases where lockdown is used without Secure Boot. To defeat lockdown, boot without Secure Boot and add ima_appraise=log to the kernel command line; then: $ echo "integrity" > /sys/kernel/security/lockdown $ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" > \ /sys/kernel/security/ima/policy $ kexec -ls unsigned-kernel Add a call to verify ima appraisal is set to "enforce" whenever lockdown is enabled. This fixes CVE-2022-21505. Cc: stable@vger.kernel.org Fixes: 29d3c1c8 ("kexec: Allow kexec_file() with appropriate IMA policy when locked down") Signed-off-by: NEric Snowberg <eric.snowberg@oracle.com> Acked-by: NMimi Zohar <zohar@linux.ibm.com> Reviewed-by: NJohn Haxby <john.haxby@oracle.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGUO Zihua <guozihua@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Helge Deller 提交于
stable inclusion from stable-v5.10.130 commit b81212828ad19ab3eccf00626cd04099215060bf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IQ4M CVE: CVE-2021-33655 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b81212828ad19ab3eccf00626cd04099215060bf -------------------------------- commit 6c11df58 upstream. Verify that the fbdev or drm driver correctly adjusted the virtual screen sizes. On failure report the failing driver and reject the screen size change. Signed-off-by: NHelge Deller <deller@gmx.de> Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Helge Deller 提交于
stable inclusion from stable-v5.10.130 commit cecb806c766c78e1be62b6b7b1483ef59bbaeabe category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IQ4M CVE: CVE-2021-33655 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cecb806c766c78e1be62b6b7b1483ef59bbaeabe -------------------------------- commit e64242ca upstream. We need to prevent that users configure a screen size which is smaller than the currently selected font size. Otherwise rendering chars on the screen will access memory outside the graphics memory region. This patch adds a new function fbcon_modechange_possible() which implements this check and which later may be extended with other checks if necessary. The new function is called from the FBIOPUT_VSCREENINFO ioctl handler in fbmem.c, which will return -EINVAL if userspace asked for a too small screen size. Signed-off-by: NHelge Deller <deller@gmx.de> Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Helge Deller 提交于
stable inclusion from stable-v5.10.130 commit b727561ddc9360de9631af2d970d8ffed676a750 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IQ4M CVE: CVE-2021-33655 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b727561ddc9360de9631af2d970d8ffed676a750 -------------------------------- commit 65a01e60 upstream. Prevent that users set a font size which is bigger than the physical screen. It's unlikely this may happen (because screens are usually much larger than the fonts and each font char is limited to 32x32 pixels), but it may happen on smaller screens/LCD displays. Signed-off-by: NHelge Deller <deller@gmx.de> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Amir Goldstein 提交于
mainline inclusion from mainline-v5.19-rc1 commit a32e697c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IHD1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a32e697cda27679a0327ae2cafdad8c7170f548f -------------------------------- The inotify mask flags IN_ONESHOT and IN_EXCL_UNLINK are not "internal to kernel" and should be exposed in procfs fdinfo so CRIU can restore them. Fixes: 69335996 ("inotify: hide internal kernel bits from fdinfo") Link: https://lore.kernel.org/r/20220422120327.3459282-2-amir73il@gmail.comSigned-off-by: NAmir Goldstein <amir73il@gmail.com> Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA -------------------------------- Patch ("block: fix that part scan is disabled in device_add_disk()") confuse lockdep to produce following warning: ===================================================== WARNING: possible circular locking dependency detected 4.18.0+ #2 Tainted: G ---------r- - ------------------------------------------------------ syz-executor.0/4652 is trying to acquire lock: 00000000ad5f5a19 (&mddev->open_mutex){+.+.}, at: md_open+0x13a/0x260 home/install/linux-rh-3-10/drivers/md/md.c:7626 but task is already holding lock: 000000005c3a3fea (&bdev->bd_mutex){+.+.}, at: __blkdev_get+0x156/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1583 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&bdev->bd_mutex){+.+.}: __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 __blkdev_get+0x156/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1583 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 disk_init_partition home/install/linux-rh-3-10/block/blk-sysfs.c:972 [inline] blk_register_queue+0x5ed/0x6c0 home/install/linux-rh-3-10/block/blk-sysfs.c:1055 __device_add_disk+0xab5/0xd70 home/install/linux-rh-3-10/block/genhd.c:729 sd_probe_async+0x447/0x852 home/install/linux-rh-3-10/drivers/scsi/sd.c:3249 async_run_entry_fn+0xe1/0x700 home/install/linux-rh-3-10/kernel/async.c:127 process_one_work+0x9cf/0x1940 home/install/linux-rh-3-10/kernel/workqueue.c:2175 worker_thread+0x91/0xc50 home/install/linux-rh-3-10/kernel/workqueue.c:2321 kthread+0x33a/0x400 home/install/linux-rh-3-10/kernel/kthread.c:257 ret_from_fork+0x3a/0x50 home/install/linux-rh-3-10/arch/x86/entry/entry_64.S:355 -> #1 (&q->sysfs_dir_lock){+.+.}: __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 blk_register_queue+0x143/0x6c0 home/install/linux-rh-3-10/block/blk-sysfs.c:1010 __device_add_disk+0xab5/0xd70 home/install/linux-rh-3-10/block/genhd.c:729 add_disk home/install/linux-rh-3-10/./include/linux/genhd.h:447 [inline] md_alloc+0xb06/0x10d0 home/install/linux-rh-3-10/drivers/md/md.c:5525 md_probe+0x32/0x60 home/install/linux-rh-3-10/drivers/md/md.c:5554 kobj_lookup+0x2d2/0x450 home/install/linux-rh-3-10/drivers/base/map.c:152 get_gendisk+0x3b/0x360 home/install/linux-rh-3-10/block/genhd.c:860 bdev_get_gendisk home/install/linux-rh-3-10/fs/block_dev.c:1181 [inline] __blkdev_get+0x3b6/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1578 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 blkdev_open+0x1c2/0x250 home/install/linux-rh-3-10/fs/block_dev.c:1923 do_dentry_open+0x686/0xf50 home/install/linux-rh-3-10/fs/open.c:777 do_last home/install/linux-rh-3-10/fs/namei.c:3449 [inline] path_openat+0x92f/0x28c0 home/install/linux-rh-3-10/fs/namei.c:3578 do_filp_open+0x1aa/0x2b0 home/install/linux-rh-3-10/fs/namei.c:3613 do_sys_open+0x307/0x490 home/install/linux-rh-3-10/fs/open.c:1075 do_syscall_64+0xca/0x5c0 home/install/linux-rh-3-10/arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf -> #0 (&mddev->open_mutex){+.+.}: lock_acquire+0x10b/0x3a0 home/install/linux-rh-3-10/kernel/locking/lockdep.c:3868 __mutex_lock_common home/install/linux-rh-3-10/kernel/locking/mutex.c:925 [inline] __mutex_lock+0x105/0x1270 home/install/linux-rh-3-10/kernel/locking/mutex.c:1072 md_open+0x13a/0x260 home/install/linux-rh-3-10/drivers/md/md.c:7626 __blkdev_get+0x2dc/0x1490 home/install/linux-rh-3-10/fs/block_dev.c:1599 blkdev_get+0x33c/0xac0 home/install/linux-rh-3-10/fs/block_dev.c:1735 blkdev_open+0x1c2/0x250 home/install/linux-rh-3-10/fs/block_dev.c:1923 do_dentry_open+0x686/0xf50 home/install/linux-rh-3-10/fs/open.c:777 do_last home/install/linux-rh-3-10/fs/namei.c:3449 [inline] path_openat+0x92f/0x28c0 home/install/linux-rh-3-10/fs/namei.c:3578 do_filp_open+0x1aa/0x2b0 home/install/linux-rh-3-10/fs/namei.c:3613 do_sys_open+0x307/0x490 home/install/linux-rh-3-10/fs/open.c:1075 do_syscall_64+0xca/0x5c0 home/install/linux-rh-3-10/arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x6a/0xdf other info that might help us debug this: Chain exists of: &mddev->open_mutex --> &q->sysfs_dir_lock --> &bdev->bd_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&bdev->bd_mutex); lock(&q->sysfs_dir_lock); lock(&bdev->bd_mutex); lock(&mddev->open_mutex); *** DEADLOCK *** Since 'bd_mutex' and 'sysfs_dir_lock' is different is for each device, deadlock between md_open() and sd_probe_async() is impossible. However, lockdep is treating 'bd_mutex' and 'sysfs_dir_lock' from different devices the same, and patch "block: fix that part scan is disabled in device_add_disk()" is holding 'bd_mutex' inside 'sysfs_dir_lock', which causes the false positive warning. Fix the false positive warning by don't grab 'bd_mutex' inside 'sysfs_dir_lock'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA -------------------------------- Patch ("block: Fix warning in bd_link_disk_holder()") moves the setting of flag 'GENHD_FL_UP' behind blkdev_get, which will disabled part scan: devcie_add_disk register_disk blkdev_get __blkdev_get bdev_get_gendisk get_gendisk -> failed because 'GENHD_FL_UP' is not set And this will cause tests block/017, block/018 and scsi/004 to fail. Fix the problem by moving part scan as well. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luo Meng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA -------------------------------- Warning reports as follows: WARNING: CPU: 3 PID: 674 at fs/block_dev.c:1272 bd_link_disk_holder+0xcd/0x270 Modules linked in: null_blk(+) CPU: 3 PID: 674 Comm: dmsetup Not tainted 5.10.0-16691-gf6076432827d-dirty #158 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4 RIP: 0010:bd_link_disk_holder+0xcd/0x270 Code: 69 73 ee 00 44 89 e8 5b 48 83 05 c5 bf 6d 0c 01 5d 41 5c 41 5d 41 5e 41 8 RSP: 0018:ffffc9000049bbb8 EFLAGS: 00010202 RAX: ffff888104e39038 RBX: ffff888104185000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffffaa085692 RDI: 0000000000000000 RBP: ffff88810cc2ae00 R08: ffffffffa853659b R09: 0000000000000000 R10: ffffc9000049bbb0 R11: 720030626c6c756e R12: ffff88810e800000 R13: ffff88810e800090 R14: ffff888103570c98 R15: ffff888103570c80 FS: 00007fb49dc13dc0(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff994ebde70 CR3: 000000010d54a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dm_get_table_device+0x175/0x300 dm_get_device+0x238/0x360 linear_ctr+0xee/0x170 dm_table_add_target+0x199/0x4b0 table_load+0x18c/0x480 ? table_clear+0x190/0x190 ctl_ioctl+0x21d/0x640 ? check_preemption_disabled+0x140/0x150 dm_ctl_ioctl+0x12/0x20 __se_sys_ioctl+0xb1/0x100 __x64_sys_ioctl+0x1e/0x30 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This can reproduce by concurrent operations: 1. modprobe null_blk 2. echo -e "0 10000 linear /dev/nullb0 0" > table dmsetup create xxx table t1: create disk a | t2: dm setup | device_add_disk | dev->devt = devt | | dm_get_table_device | open_table_device | blkdev_get_by_dev -> succeed | bd_link_disk_holder | -> holder_dir is still NULL register_disk -> create holder_dir kobject_create_and_add device_add_disk() will set devt before creating holder_dir, which leaves a window that dm_get_table_device() can find the disk by devt while it's holder_dir is NULL. So move GENHD_FL_UP in blk_register_queue() to avoid this warning and fix a NULL-ptr in __blk_mq_sched_bio_merge(). Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sven Schnelle 提交于
mainline inclusion from mainline-v5.14-rc6 commit f153c224 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5IDIC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f153c2246783ba210493054d99c66353f56423c9 -------------------------------- commit f9c82a4e ("Increase size of ucounts to atomic_long_t") changed the data type of ucounts/ucounts_max to long, but missed to adjust a few other places. This is noticeable on big endian platforms from user space because the /proc/sys/user/max_*_names files all contain 0. v4 - Made the min and max constants long so the sysctl values are actually settable on little endian machines. -- EWB Fixes: f9c82a4e ("Increase size of ucounts to atomic_long_t") Signed-off-by: NSven Schnelle <svens@linux.ibm.com> Tested-by: NNathan Chancellor <nathan@kernel.org> Tested-by: NLinux Kernel Functional Testing <lkft@linaro.org> Acked-by: NAlexey Gladkov <legion@kernel.org> v1: https://lkml.kernel.org/r/20210721115800.910778-1-svens@linux.ibm.com v2: https://lkml.kernel.org/r/20210721125233.1041429-1-svens@linux.ibm.com v3: https://lkml.kernel.org/r/20210730062854.3601635-1-svens@linux.ibm.com Link: https://lkml.kernel.org/r/8735rijqlv.fsf_-_@disp2133Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Conflict: fs/notify/fanotify/fanotify_user.c Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhengchao Shao 提交于
mainline inclusion from mainline-v5.19-rc6 commit fd189422 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5HWKR CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fd1894224407 -------------------------------- Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5 LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NStanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/r/20220715115559.139691-1-shaozhengchao@huawei.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 26 7月, 2022 28 次提交
-
-
由 Marek Vasut 提交于
stable inclusion from stable-v5.10.113 commit 7992fdb045fbc7cb0e34eba464b73044585c0638 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7992fdb045fbc7cb0e34eba464b73044585c0638 -------------------------------- This reverts commit 1ff5359afa5ec0dd09fe76183dc4fa24b50e4125 which is commit c3efcedd upstream. The upstream commit c3efcedd ("net: micrel: fix KS8851_MLL Kconfig") depends on e5f31552 ("ethernet: fix PTP_1588_CLOCK dependencies") which is not part of Linux 5.10.y . Revert the aforementioned commit to prevent breakage in 5.10.y . Signed-off-by: NMarek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Sasha Levin <sashal@kernel.org> Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Khazhismel Kumykov 提交于
stable inclusion from stable-v5.10.113 commit 8bedbc8f7f35f533000b347644b6bf1f62524676 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8bedbc8f7f35f533000b347644b6bf1f62524676 -------------------------------- commit ccf16413 upstream. kernel ulong and compat_ulong_t may not be same width. Use type directly to eliminate mismatches. This would result in truncation rather than EFBIG for 32bit mode for large disks. Reviewed-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NKhazhismel Kumykov <khazhy@google.com> Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20220414224056.2875681-1-khazhy@google.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Lee Jones 提交于
stable inclusion from stable-v5.10.113 commit fea24b07edfc348c67a019b6e17b39c0698e631f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fea24b07edfc348c67a019b6e17b39c0698e631f -------------------------------- Supply additional check in order to prevent unexpected results. Fixes: b892bf75 ("ion: Switch ion to use dma-buf") Suggested-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLee Jones <lee.jones@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Tudor Ambarus 提交于
stable inclusion from stable-v5.10.113 commit dccee748af17fc087ff5017152e532ef8e18c8c0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dccee748af17fc087ff5017152e532ef8e18c8c0 -------------------------------- commit 8c235cc2 upstream. Use the spi_mem_default_supports_op() core helper in order to take into account the buswidth specified by the user in device tree. Cc: <stable@vger.kernel.org> Fixes: 0e6aae08 ("spi: Add QuadSPI driver for Atmel SAMA5D2") Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20220406133604.455356-1-tudor.ambarus@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Oliver Hartkopp 提交于
stable inclusion from stable-v5.10.113 commit 50aac44273600cb0ae1efd010bb1de7701444a41 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=50aac44273600cb0ae1efd010bb1de7701444a41 -------------------------------- commit d7349708 upstream. The first attempt to fix a the 'impossible' WARN_ON_ONCE(1) in isotp_tx_timer_handler() focussed on the identical CAN IDs created by the syzbot reproducer and lead to upstream fix/commit 3ea56642 ("can: isotp: sanitize CAN ID checks in isotp_bind()"). But this did not catch the root cause of the wrong tx.state in the tx_timer handler. In the isotp 'first frame' case a timeout monitoring needs to be started before the 'first frame' is send. But when this sending failed the timeout monitoring for this specific frame has to be disabled too. Otherwise the tx_timer is fired with the 'warn me' tx.state of ISOTP_IDLE. Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/all/20220405175112.2682-1-socketcan@hartkopp.net Reported-by: syzbot+2339c27f5c66c652843e@syzkaller.appspotmail.com Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Theodore Ts'o 提交于
stable inclusion from stable-v5.10.113 commit e1e96e37272156d691203a3725b876787f38c8f2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e1e96e37272156d691203a3725b876787f38c8f2 -------------------------------- commit 85d825db upstream. If the file system does not use bigalloc, calculating the overhead is cheap, so force the recalculation of the overhead so we don't have to trust the precalculated overhead in the superblock. Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Theodore Ts'o 提交于
stable inclusion from stable-v5.10.113 commit 4789149b9ea2a1893c62d816742f1a76514fc901 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4789149b9ea2a1893c62d816742f1a76514fc901 -------------------------------- commit 10b01ee9 upstream. The kernel calculation was underestimating the overhead by not taking into account the reserved gdt blocks. With this change, the overhead calculated by the kernel matches the overhead calculation in mke2fs. Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 wangjianjian (C) 提交于
stable inclusion from stable-v5.10.113 commit 0c54b093766becb9c83317232c93290cf612b8ff category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0c54b093766becb9c83317232c93290cf612b8ff -------------------------------- commit 7102ffe4 upstream. According to document and code, ext4_xattr_header's size is 32 bytes, so h_reserved size should be 3. Signed-off-by: NWang Jianjian <wangjianjian3@huawei.com> Link: https://lore.kernel.org/r/92fcc3a6-7d77-8c09-4126-377fcb4c46a5@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Tadeusz Struk 提交于
stable inclusion from stable-v5.10.113 commit 22c450d39f8922ae26de459cf4f83b2b294f207e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=22c450d39f8922ae26de459cf4f83b2b294f207e -------------------------------- commit 2da37622 upstream. Syzbot found an issue [1] in ext4_fallocate(). The C reproducer [2] calls fallocate(), passing size 0xffeffeff000ul, and offset 0x1000000ul, which, when added together exceed the bitmap_maxbytes for the inode. This triggers a BUG in ext4_ind_remove_space(). According to the comments in this function the 'end' parameter needs to be one block after the last block to be removed. In the case when the BUG is triggered it points to the last block. Modify the ext4_punch_hole() function and add constraint that caps the length to satisfy the one before laster block requirement. LINK: [1] https://syzkaller.appspot.com/bug?id=b80bd9cf348aac724a4f4dff251800106d721331 LINK: [2] https://syzkaller.appspot.com/text?tag=ReproC&x=14ba0238700000 Fixes: a4bb6b64 ("ext4: enable "punch hole" functionality") Reported-by: syzbot+7a806094edd5d07ba029@syzkaller.appspotmail.com Signed-off-by: NTadeusz Struk <tadeusz.struk@linaro.org> Link: https://lore.kernel.org/r/20220331200515.153214-1-tadeusz.struk@linaro.orgSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Darrick J. Wong 提交于
stable inclusion from stable-v5.10.113 commit f6038d43b25bba1cd50d2a77e207f6550aee9954 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f6038d43b25bba1cd50d2a77e207f6550aee9954 -------------------------------- commit ad5cd4f4 upstream. Since the initial introduction of (posix) fallocate back at the turn of the century, it has been possible to use this syscall to change the user-visible contents of files. This can happen by extending the file size during a preallocation, or through any of the newer modes (punch, zero, collapse, insert range). Because the call can be used to change file contents, we should treat it like we do any other modification to a file -- update the mtime, and drop set[ug]id privileges/capabilities. The VFS function file_modified() does all this for us if pass it a locked inode, so let's make fallocate drop permissions correctly. Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Link: https://lore.kernel.org/r/20220308185043.GA117678@magnoliaSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Leo Yan 提交于
stable inclusion from stable-v5.10.113 commit 19590bbc691d81f03d2a24a3ec30c399ebe071e0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19590bbc691d81f03d2a24a3ec30c399ebe071e0 -------------------------------- [ Upstream commit ccb17cae ] Since commit bb30acae ("perf report: Bail out --mem-mode if mem info is not available") "perf mem report" and "perf report --mem-mode" don't report result if the PERF_SAMPLE_DATA_SRC bit is missed in sample type. The commit ffab4870 ("perf: arm-spe: Fix perf report --mem-mode") partially fixes the issue. It adds PERF_SAMPLE_DATA_SRC bit for Arm SPE event, this allows the perf data file generated by kernel v5.18-rc1 or later version can be reported properly. On the other hand, perf tool still fails to be backward compatibility for a data file recorded by an older version's perf which contains Arm SPE trace data. This patch is a workaround in reporting phase, when detects ARM SPE PMU event and without PERF_SAMPLE_DATA_SRC bit, it will force to set the bit in the sample type and give a warning info. Fixes: bb30acae ("perf report: Bail out --mem-mode if mem info is not available") Reviewed-by: NJames Clark <james.clark@arm.com> Signed-off-by: NLeo Yan <leo.yan@linaro.org> Tested-by: NGerman Gomez <german.gomez@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Link: https://lore.kernel.org/r/20220414123201.842754-1-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Athira Rajeev 提交于
stable inclusion from stable-v5.10.113 commit e012f9d1af54ca3c24ca0e9ec03a1a212972771c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e012f9d1af54ca3c24ca0e9ec03a1a212972771c -------------------------------- [ Upstream commit 0dcad700 ] When scheduling a group of events, there are constraint checks done to make sure all events can go in a group. Example, one of the criteria is that events in a group cannot use the same PMC. But platform specific PMU supports alternative event for some of the event codes. During perf_event_open(), if any event group doesn't match constraint check criteria, further lookup is done to find alternative event. By current design, the array of alternatives events in PMU code is expected to be sorted by column 0. This is because in find_alternative() the return criteria is based on event code comparison. ie. "event < ev_alt[i][0])". This optimisation is there since find_alternative() can be called multiple times. In power9 PMU code, the alternative event array is not sorted properly and hence there is breakage in finding alternative events. To work with existing logic, fix the alternative event array to be sorted by column 0 for power9-pmu.c Results: With alternative events, multiplexing can be avoided. That is, for example, in power9 PM_LD_MISS_L1 (0x3e054) has alternative event, PM_LD_MISS_L1_ALT (0x400f0). This is an identical event which can be programmed in a different PMC. Before: # perf stat -e r3e054,r300fc Performance counter stats for 'system wide': 1057860 r3e054 (50.21%) 379 r300fc (49.79%) 0.944329741 seconds time elapsed Since both the events are using PMC3 in this case, they are multiplexed here. After: # perf stat -e r3e054,r300fc Performance counter stats for 'system wide': 1006948 r3e054 182 r300fc Fixes: 91e0bd1e ("powerpc/perf: Add PM_LD_MISS_L1 and PM_BR_2PATH to power9 event list") Signed-off-by: NAthira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220419114828.89843-1-atrajeev@linux.vnet.ibm.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Miaoqian Lin 提交于
stable inclusion from stable-v5.10.113 commit 0a2cef65b32919af7df4df979c5eede5f7825f17 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a2cef65b32919af7df4df979c5eede5f7825f17 -------------------------------- [ Upstream commit 3d0b93d9 ] If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1. Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync() fails, so use pm_runtime_resume_and_get() instead. this function will handle this. Fixes: 4078f575 ("drm/vc4: Add DSI driver") Signed-off-by: NMiaoqian Lin <linmq006@gmail.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220420135008.2757-1-linmq006@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Alexey Kardashevskiy 提交于
stable inclusion from stable-v5.10.113 commit f8f8b3124b899867a18a3f63e538c791e21252ac category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f8f8b3124b899867a18a3f63e538c791e21252ac -------------------------------- [ Upstream commit 26a62b75 ] The LoPAPR spec defines a guest visible IOMMU with a variable page size. Currently QEMU advertises 4K, 64K, 2M, 16MB pages, a Linux VM picks the biggest (16MB). In the case of a passed though PCI device, there is a hardware IOMMU which does not support all pages sizes from the above - P8 cannot do 2MB and P9 cannot do 16MB. So for each emulated 16M IOMMU page we may create several smaller mappings ("TCEs") in the hardware IOMMU. The code wrongly uses the emulated TCE index instead of hardware TCE index in error handling. The problem is easier to see on POWER8 with multi-level TCE tables (when only the first level is preallocated) as hash mode uses real mode TCE hypercalls handlers. The kernel starts using indirect tables when VMs get bigger than 128GB (depends on the max page order). The very first real mode hcall is going to fail with H_TOO_HARD as in the real mode we cannot allocate memory for TCEs (we can in the virtual mode) but on the way out the code attempts to clear hardware TCEs using emulated TCE indexes which corrupts random kernel memory because it_offset==1<<59 is subtracted from those indexes and the resulting index is out of the TCE table bounds. This fixes kvmppc_clear_tce() to use the correct TCE indexes. While at it, this fixes TCE cache invalidation which uses emulated TCE indexes instead of the hardware ones. This went unnoticed as 64bit DMA is used these days and VMs map all RAM in one go and only then do DMA and this is when the TCE cache gets populated. Potentially this could slow down mapping, however normally 16MB emulated pages are backed by 64K hardware pages so it is one write to the "TCE Kill" per 256 updates which is not that bad considering the size of the cache (1024 TCEs or so). Fixes: ca1fc489 ("KVM: PPC: Book3S: Allow backing bigger guest IOMMU pages with smaller physical pages") Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Tested-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NFrederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220420050840.328223-1-aik@ozlabs.ruSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dave Stevenson 提交于
stable inclusion from stable-v5.10.113 commit 405d98427416849cf37c84c0c70bd5008b686a1e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=405d98427416849cf37c84c0c70bd5008b686a1e -------------------------------- [ Upstream commit 5f18c078 ] The panel has a prepare call which is before video starts, and an enable call which is after. The Toshiba bridge should be configured before video, so move the relevant power and initialisation calls to prepare. Fixes: 2f733d61 ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220415162513.42190-3-stefan.wahren@i2se.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dave Stevenson 提交于
stable inclusion from stable-v5.10.113 commit 231381f5211620cec836b921f1c7a2cf702b3e8a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=231381f5211620cec836b921f1c7a2cf702b3e8a -------------------------------- [ Upstream commit f92055ae ] If a call to rpi_touchscreen_i2c_write from rpi_touchscreen_probe fails before mipi_dsi_device_register_full is called, then in trying to log the error message if uses ts->dsi->dev when it is still NULL. Use ts->i2c->dev instead, which is initialised earlier in probe. Fixes: 2f733d61 ("drm/panel: Add support for the Raspberry Pi 7" Touchscreen.") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220415162513.42190-2-stefan.wahren@i2se.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Zhipeng Xie 提交于
stable inclusion from stable-v5.10.113 commit 51d9cbbb0f5a175e5b4c4a25d2ec995363304860 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=51d9cbbb0f5a175e5b4c4a25d2ec995363304860 -------------------------------- [ Upstream commit 60490e79 ] This problem can be reproduced with CONFIG_PERF_USE_VMALLOC enabled on both x86_64 and aarch64 arch when using sysdig -B(using ebpf)[1]. sysdig -B works fine after rebuilding the kernel with CONFIG_PERF_USE_VMALLOC disabled. I tracked it down to the if condition event->rb->nr_pages != nr_pages in perf_mmap is true when CONFIG_PERF_USE_VMALLOC is enabled where event->rb->nr_pages = 1 and nr_pages = 2048 resulting perf_mmap to return -EINVAL. This is because when CONFIG_PERF_USE_VMALLOC is enabled, rb->nr_pages is always equal to 1. Arch with CONFIG_PERF_USE_VMALLOC enabled by default: arc/arm/csky/mips/sh/sparc/xtensa Arch with CONFIG_PERF_USE_VMALLOC disabled by default: x86_64/aarch64/... Fix this problem by using data_page_nr() [1] https://github.com/draios/sysdig Fixes: 906010b2 ("perf_event: Provide vmalloc() based mmap() backing") Signed-off-by: NZhipeng Xie <xiezhipeng1@huawei.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220209145417.6495-1-xiezhipeng1@huawei.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 kuyo chang 提交于
stable inclusion from stable-v5.10.113 commit 88fcfd6ee6c5a617e712b346e9c15fc3057e532e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=88fcfd6ee6c5a617e712b346e9c15fc3057e532e -------------------------------- [ Upstream commit 40f5aa4c ] The warning in cfs_rq_is_decayed() triggered: SCHED_WARN_ON(cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg) There exists a corner case in attach_entity_load_avg() which will cause load_sum to be zero while load_avg will not be. Consider se_weight is 88761 as per the sched_prio_to_weight[] table. Further assume the get_pelt_divider() is 47742, this gives: se->avg.load_avg is 1. However, calculating load_sum: se->avg.load_sum = div_u64(se->avg.load_avg * se->avg.load_sum, se_weight(se)); se->avg.load_sum = 1*47742/88761 = 0. Then enqueue_load_avg() adds this to the cfs_rq totals: cfs_rq->avg.load_avg += se->avg.load_avg; cfs_rq->avg.load_sum += se_weight(se) * se->avg.load_sum; Resulting in load_avg being 1 with load_sum is 0, which will trigger the WARN. Fixes: f207934f ("sched/fair: Align PELT windows between cfs_rq and its se") Signed-off-by: Nkuyo chang <kuyo.chang@mediatek.com> [peterz: massage changelog] Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NVincent Guittot <vincent.guittot@linaro.org> Tested-by: NDietmar Eggemann <dietmar.eggemann@arm.com> Link: https://lkml.kernel.org/r/20220414090229.342-1-kuyo.chang@mediatek.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Rob Herring 提交于
stable inclusion from stable-v5.10.113 commit c55327bc3712ca96dc05bc4c6aab805b6fa8bb74 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c55327bc3712ca96dc05bc4c6aab805b6fa8bb74 -------------------------------- commit e5c23779 upstream. In the case where there is only a cycle counter available (i.e. PMCR_EL0.N is 0) and an event other than CPU cycles is opened, the open should fail as the event can never possibly be scheduled. However, the event validation when an event is opened is skipped when the group leader is opened. Fix this by always validating the group leader events. Reported-by: NAl Grant <al.grant@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: NRob Herring <robh@kernel.org> Acked-by: NMark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220408203330.4014015-1-robh@kernel.org Cc: <stable@vger.kernel.org> Signed-off-by: NWill Deacon <will@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sergey Matyukevich 提交于
stable inclusion from stable-v5.10.113 commit 5580b974a84b30f6da90a3a562ea0dbfb0038110 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5580b974a84b30f6da90a3a562ea0dbfb0038110 -------------------------------- commit b1c6ecfd upstream. Function syscall_trace_exit expects pointer to pt_regs. However r0 is also used to keep syscall return value. Restore pointer to pt_regs before calling syscall_trace_exit. Cc: <stable@vger.kernel.org> Signed-off-by: NSergey Matyukevich <sergey.matyukevich@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Sasha Neftin 提交于
stable inclusion from stable-v5.10.113 commit 7082650eb8265b583d0aea0515bcc6f65b0e8755 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7082650eb8265b583d0aea0515bcc6f65b0e8755 -------------------------------- commit 04ebaa1c upstream. When we decode the latency and the max_latency, u16 value may not fit the required size and could lead to the wrong LTR representation. Scaling is represented as: scale 0 - 1 (2^(5*0)) = 2^0 scale 1 - 32 (2^(5 *1))= 2^5 scale 2 - 1024 (2^(5 *2)) =2^10 scale 3 - 32768 (2^(5 *3)) =2^15 scale 4 - 1048576 (2^(5 *4)) = 2^20 scale 5 - 33554432 (2^(5 *4)) = 2^25 scale 4 and scale 5 required 20 and 25 bits respectively. scale 6 reserved. Replace the u16 type with the u32 type and allow corrected LTR representation. Cc: stable@vger.kernel.org Fixes: 44a13a5d ("e1000e: Fix the max snoop/no-snoop latency for 10M") Reported-by: NJames Hutchinson <jahutchinson99@googlemail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215689Suggested-by: NDima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: NSasha Neftin <sasha.neftin@intel.com> Tested-by: NNaama Meir <naamax.meir@linux.intel.com> Tested-by: NJames Hutchinson <jahutchinson99@googlemail.com> Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Xiaomeng Tong 提交于
stable inclusion from stable-v5.10.113 commit 43a2a3734aa3d25ef11b90f14f18bf31fb0a7feb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=43a2a3734aa3d25ef11b90f14f18bf31fb0a7feb -------------------------------- commit f730a46b upstream. These two bug are here: list_for_each_entry_safe_continue(w, n, list, power_list); list_for_each_entry_safe_continue(w, n, list, power_list); After the list_for_each_entry_safe_continue() exits, the list iterator will always be a bogus pointer which point to an invalid struct objdect containing HEAD member. The funciton poniter 'w->event' will be a invalid value which can lead to a control-flow hijack if the 'w' can be controlled. The original intention was to continue the outer list_for_each_entry_safe() loop with the same entry if w->event is NULL, but misunderstanding the meaning of list_for_each_entry_safe_continue(). So just add a 'continue;' to fix the bug. Cc: stable@vger.kernel.org Fixes: 163cac06 ("ASoC: Factor out DAPM sequence execution") Signed-off-by: NXiaomeng Tong <xiam0nd.tong@gmail.com> Link: https://lore.kernel.org/r/20220329012134.9375-1-xiam0nd.tong@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Mario Limonciello 提交于
stable inclusion from stable-v5.10.113 commit 54e6180c8c2d71b6f1fab0d1420f65299b26953e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=54e6180c8c2d71b6f1fab0d1420f65299b26953e -------------------------------- commit 06fb4ecf upstream. Commit 5467801f ("gpio: Restrict usage of GPIO chip irq members before initialization") attempted to fix a race condition that lead to a NULL pointer, but in the process caused a regression for _AEI/_EVT declared GPIOs. This manifests in messages showing deferred probing while trying to allocate IRQs like so: amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517 [ .. more of the same .. ] The code for walking _AEI doesn't handle deferred probing and so this leads to non-functional GPIO interrupts. Fix this issue by moving the call to `acpi_gpiochip_request_interrupts` to occur after gc->irc.initialized is set. Fixes: 5467801f ("gpio: Restrict usage of GPIO chip irq members before initialization") Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/ Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976Reported-by: NMario Limonciello <mario.limonciello@amd.com> Signed-off-by: NMario Limonciello <mario.limonciello@amd.com> Reviewed-by: NShreeya Patel <shreeya.patel@collabora.com> Tested-By: NSamuel Čavoj <samuel@cavoj.net> Tested-By: lukeluk498@gmail.com Link: Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-and-tested-by: NTakashi Iwai <tiwai@suse.de> Cc: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Paolo Valerio 提交于
stable inclusion from stable-v5.10.113 commit 0837ff17d052b7d755d5086208c3445867aaff82 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0837ff17d052b7d755d5086208c3445867aaff82 -------------------------------- commit cefa91b2 upstream. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, if next_offset is greater than MAX_ACTIONS_BUFSIZE, the function reserve_sfa_size() does not return -EMSGSIZE as expected, but it allocates MAX_ACTIONS_BUFSIZE bytes increasing actions_len by req_size. This can then lead to an OOB write access, especially when further actions need to be copied. Fix it by rearranging the flow action size check. KASAN splat below: Acked-by: NXie XiuQi <xiexiuqi@huawei.com> ================================================================== BUG: KASAN: slab-out-of-bounds in reserve_sfa_size+0x1ba/0x380 [openvswitch] Write of size 65360 at addr ffff888147e4001c by task handler15/836 CPU: 1 PID: 836 Comm: handler15 Not tainted 5.18.0-rc1+ #27 ... Call Trace: <TASK> dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? reserve_sfa_size+0x1ba/0x380 [openvswitch] kasan_report+0xb5/0x130 ? reserve_sfa_size+0x1ba/0x380 [openvswitch] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 reserve_sfa_size+0x1ba/0x380 [openvswitch] __add_action+0x24/0x120 [openvswitch] ovs_nla_add_action+0xe/0x20 [openvswitch] ovs_ct_copy_action+0x29d/0x1130 [openvswitch] ? __kernel_text_address+0xe/0x30 ? unwind_get_return_address+0x56/0xa0 ? create_prof_cpu_mask+0x20/0x20 ? ovs_ct_verify+0xf0/0xf0 [openvswitch] ? prep_compound_page+0x198/0x2a0 ? __kasan_check_byte+0x10/0x40 ? kasan_unpoison+0x40/0x70 ? ksize+0x44/0x60 ? reserve_sfa_size+0x75/0x380 [openvswitch] __ovs_nla_copy_actions+0xc26/0x2070 [openvswitch] ? __zone_watermark_ok+0x420/0x420 ? validate_set.constprop.0+0xc90/0xc90 [openvswitch] ? __alloc_pages+0x1a9/0x3e0 ? __alloc_pages_slowpath.constprop.0+0x1da0/0x1da0 ? unwind_next_frame+0x991/0x1e40 ? __mod_node_page_state+0x99/0x120 ? __mod_lruvec_page_state+0x2e3/0x470 ? __kasan_kmalloc_large+0x90/0xe0 ovs_nla_copy_actions+0x1b4/0x2c0 [openvswitch] ovs_flow_cmd_new+0x3cd/0xb10 [openvswitch] ... Cc: stable@vger.kernel.org Fixes: f28cd2af ("openvswitch: fix flow actions reallocation") Signed-off-by: NPaolo Valerio <pvalerio@redhat.com> Acked-by: NEelco Chaudron <echaudro@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Max Filippov 提交于
stable inclusion from stable-v5.10.113 commit 19f6dcb1f0f0f8523976c8aa1800856c9b4f35c3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19f6dcb1f0f0f8523976c8aa1800856c9b4f35c3 -------------------------------- commit 839769c3 upstream. Fast coprocessor exception handler saves a3..a6, but coprocessor context load/store code uses a4..a7 as temporaries, potentially clobbering a7. 'Potentially' because coprocessor state load/store macros may not use all four temporary registers (and neither FPU nor HiFi macros do). Use a3..a6 as intended. Cc: stable@vger.kernel.org Fixes: c658eac6 ("[XTENSA] Add support for configurable registers and coprocessors") Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Guo Ren 提交于
stable inclusion from stable-v5.10.113 commit f399ab11dd6cc0a6927029371fbe2ec027181598 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f399ab11dd6cc0a6927029371fbe2ec027181598 -------------------------------- commit ee69d4be upstream. These patch_text implementations are using stop_machine_cpuslocked infrastructure with atomic cpu_count. The original idea: When the master CPU patch_text, the others should wait for it. But current implementation is using the first CPU as master, which couldn't guarantee the remaining CPUs are waiting. This patch changes the last CPU as the master to solve the potential risk. Fixes: 64711f9a ("xtensa: implement jump_label support") Signed-off-by: NGuo Ren <guoren@linux.alibaba.com> Signed-off-by: NGuo Ren <guoren@kernel.org> Reviewed-by: NMax Filippov <jcmvbkbc@gmail.com> Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org> Cc: <stable@vger.kernel.org> Message-Id: <20220407073323.743224-4-guoren@kernel.org> Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Manuel Ullmann 提交于
stable inclusion from stable-v5.10.113 commit ba2716da233618c3f361b8ece818a0e91de7a8f0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ba2716da233618c3f361b8ece818a0e91de7a8f0 -------------------------------- commit cbe6c3a8 upstream. This will reset deeply on freeze and thaw instead of suspend and resume and prevent null pointer dereferences of the uninitialized ring 0 buffer while thawing. The impact is an indefinitely hanging kernel. You can't switch consoles after this and the only possible user interaction is SysRq. BUG: kernel NULL pointer dereference RIP: 0010:aq_ring_rx_fill+0xcf/0x210 [atlantic] aq_vec_init+0x85/0xe0 [atlantic] aq_nic_init+0xf7/0x1d0 [atlantic] atl_resume_common+0x4f/0x100 [atlantic] pci_pm_thaw+0x42/0xa0 resolves in aq_ring.o to ``` 0000000000000ae0 <aq_ring_rx_fill>: { /* ... */ baf: 48 8b 43 08 mov 0x8(%rbx),%rax buff->flags = 0U; /* buff is NULL */ ``` The bug has been present since the introduction of the new pm code in 8aaa112a ("net: atlantic: refactoring pm logic") and was hidden until 8ce84271 ("net: atlantic: changes for multi-TC support"), which refactored the aq_vec_{free,alloc} functions into aq_vec_{,ring}_{free,alloc}, but is technically not wrong. The original functions just always reinitialized the buffers on S3/S4. If the interface is down before freezing, the bug does not occur. It does not matter, whether the initrd contains and loads the module before thawing. So the fix is to invert the boolean parameter deep in all pm function calls, which was clearly intended to be set like that. First report was on Github [1], which you have to guess from the resume logs in the posted dmesg snippet. Recently I posted one on Bugzilla [2], since I did not have an AQC device so far. #regzbot introduced: 8ce84271 #regzbot from: koo5 <kolman.jindrich@gmail.com> #regzbot monitor: https://github.com/Aquantia/AQtion/issues/32 Fixes: 8aaa112a ("net: atlantic: refactoring pm logic") Link: https://github.com/Aquantia/AQtion/issues/32 [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=215798 [2] Cc: stable@vger.kernel.org Reported-by: Nkoo5 <kolman.jindrich@gmail.com> Signed-off-by: NManuel Ullmann <labre@posteo.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Xiaomeng Tong 提交于
stable inclusion from stable-v5.10.113 commit 358a3846f6a950b8db803262e74081ad4ab235d4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ISAH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=358a3846f6a950b8db803262e74081ad4ab235d4 -------------------------------- commit 206680c4 upstream. The bug is here: __func__, desc, &desc->tx_dma_desc.phys, ret, cookie, residue); The list iterator 'desc' will point to a bogus position containing HEAD if the list is empty or no element is found. To avoid dev_dbg() prints a invalid address, use a new variable 'iter' as the list iterator, while use the origin variable 'desc' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 82e24246 ("dmaengine: xdmac: fix print warning on dma_addr_t variable") Signed-off-by: NXiaomeng Tong <xiam0nd.tong@gmail.com> Link: https://lore.kernel.org/r/20220327061154.4867-1-xiam0nd.tong@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-