- 29 11月, 2021 11 次提交
-
-
由 Zheng Zucheng 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- In some corner case, when we throttle the last group sched entity in rq, kernel will be panic if there is no residual sched entities in rq. So we add a protection to prevent this case. Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- When unthrottle offline tasks successfully, we should clear idle_stamp. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- If online tasks occupy 100% CPU resources, offline tasks can't be scheduled since offline tasks are throttled, as a result, offline task can't timely respond after receiving SIGKILL signal. Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- offline task invokes sched_setscheduler interface to change the scheduling policy to SCHED_OTHER, trigger a system panic. Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Chen Hui 提交于
hulk inclusion category: bugfix bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- Remove residual checkings when move tasks to new task group or write new value to the cpu.qos_level cgroup file. Signed-off-by: NChen Hui <clare.chenhui@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: feature bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- Added restrictions on modifying task scheduling policies: 1. task cannot be changed from offline to online. 2. When the scheduling policy of parent task is modified, the scheduling policy of all child node tasks is changed to be the same as that of the parent node. Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zhang Qiao 提交于
hulk inclusion category: feature bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- In order for the throttled task to continue running after the CPU is offline, we need unthrottle the throttled cfs rq saved in the qos_throttled_cfs_rq. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Chen Hui 提交于
hulk inclusion category: feature bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zhang Qiao 提交于
hulk inclusion category: feature bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- In a co-location scenario, we usually deploy online and offline task groups in the same server. The online tasks are more important than offline tasks. And to avoid offline tasks affects online tasks, we will throttle the offline tasks group when some online task groups running in the same cpu and unthrottle offline tasks when the cpu is about to enter idle state. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: feature bugzilla: 51828, https://gitee.com/openeuler/kernel/issues/I4K96G CVE: NA -------------------------------- We introduce the idea of qos level to scheduler, which now is supported with different scheduler policies. The qos scheduler will change the policy of correlative tasks when the qos level of a task group is modified with cpu.qos_level cpu cgroup file. In this way we are able to satisfy different needs of tasks in different qos levels. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 27 11月, 2021 3 次提交
-
-
由 Pavel Begunkov 提交于
mainline inclusion from mainline-v5.13-rc1 commit f70865db category: bugfix bugzilla: 185739 CVE: NA ----------------------------------------------- Revert of revert of "io_uring: wait potential ->release() on resurrect", which adds a helper for resurrect not racing completion reinit, as was removed because of a strange bug with no clear root or link to the patch. Was improved, instead of rcu_synchronize(), just wait_for_completion() because we're at 0 refs and it will happen very shortly. Specifically use non-interruptible version to ignore all pending signals that may have ended prior interruptible wait. This reverts commit cb5e1b81. Signed-off-by: NPavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/7a080c20f686d026efade810b116b72f88abaff9.1618101759.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk> conflicts: fs/io_uring.c Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Xiongfeng Wang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4HYY4?from=project-issue CVE: NA ------------------------------------------------- When I hot added a CPU, I found 'cpufreq' directory is not created below /sys/devices/system/cpu/cpuX/. It is because get_cpu_device() failed in add_cpu_dev_symlink(). cpufreq_add_dev() is the .add_dev callback of a CPU subsys interface. It will be called when the CPU device registered into the system. The stack is as follows. register_cpu() ->device_register() ->device_add() ->bus_probe_device() ->cpufreq_add_dev() But only after the CPU device has been registered, we can get the CPU device by get_cpu_device(), otherwise it will return NULL. Since we already have the CPU device in cpufreq_add_dev(), pass it to add_cpu_dev_symlink(). Signed-off-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Xiongfeng Wang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4HYY4?from=project-issue CVE: NA ------------------------------------------------- Per-CPU variables cpc_desc_ptr are initialized in acpi_cppc_processor_probe() when the processor devices are present and added into the system. But when cpu_possible_mask and cpu_present_mask is not equal, only cpc_desc_ptr in cpu_present_mask are initialized, this will cause acpi_get_psd_map() failed in cppc_cpufreq_init(). To fix this issue, we parse the _PSD method for all possible CPUs to get the P-State topology and modify acpi_get_psd_map() to rely on this information. Signed-off-by: NXiongfeng Wang <wangxiongfeng@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 24 11月, 2021 1 次提交
-
-
由 Cheng Jian 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I3OX0C CVE: NA -------------------------------- We must ensure that the following four instructions are cache-aligned. Otherwise, it will cause problems with the performance of libMicro pread. 1: # uao_user_alternative 9f, str, sttr, xzr, x0, 8 str xzr, [x0], #8 nop subs x1, x1, #8 b.pl 1b with this patch: prc thr usecs/call samples errors cnt/samp size pread_z100 1 1 5.88400 807 0 1 102400 The result of pread can range from 5 to 9 depending on the alignment performance of this function. Signed-off-by: NCheng Jian <cj.chengjian@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 23 11月, 2021 3 次提交
-
-
由 Daniel Vetter 提交于
mainline inclusion from mainline-v5.4-rc1 commit 75426367 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4JI7R CVE: NA -------------------------------- This completes Emil's series of removing DRM_UNLOCKED from modern drivers. It's entirely cargo-culted since we ignore it on non-DRIVER_LEGACY drivers since: commit ea487835 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 28 21:42:40 2015 +0200 drm: Enforce unlocked ioctl operation for kms driver ioctls Now justifying why we can do this for legacy drives too (and hence close the source of all the bogus copypasting) is a bit more involved. DRM_UNLOCKED was introduced in: commit ed8b6704 Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Dec 16 22:17:09 2009 +0000 drm: convert drm_ioctl to unlocked_ioctl As a immediate hack to keep i810 happy, which would have deadlocked without this trickery. The old BKL is automatically dropped in schedule(), and hence the i810 vs. mmap_sem deadlock didn't actually cause a real deadlock. But with a mutex it would. The solution was to annotate these as DRM_UNLOCKED and mark i810 unsafe on SMP machines. This conversion caused a regression, because unlike the BKL a mutex isn't dropped over schedule (that thing again), which caused a vblank wait in one thread to block the entire desktop and all its apps. Back then we did vblank scheduling by blocking in the client, awesome isn't it. This was fixed quickly in (ok not so quickly, took 2 years): commit 8f4ff2b0 Author: Ilija Hadzic <ihadzic@research.bell-labs.com> Date: Mon Oct 31 17:46:18 2011 -0400 drm: do not sleep on vblank while holding a mutex All the other DRM_UNLOCKED annotations for all the core ioctls was work to reach finer-grained locking for modern drivers. This took years, and culminated in: commit fdd5b877 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 10 22:52:54 2016 +0100 drm: Enforce BKL-less ioctls for modern drivers DRM_UNLOCKED was never required by any legacy drivers, except for the vblank_wait IOCTL. Therefore we will not regress these old drivers by going back to where we've been in 2011. For all modern drivers nothing will change. To make this perfectly clear, also add a comment to DRM_UNLOCKED. v2: Don't forget about drm_ioc32.c (Michel). Cc: Michel Dänzer <michel@daenzer.net> Cc: Emil Velikov <emil.l.velikov@gmail.com> Acked-by: NEmil Velikov <emil.velikov@collabora.com> Acked-by: NMichel Dänzer <michel@daenzer.net> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605120835.2798-1-daniel.vetter@ffwll.chSigned-off-by: NLiu ZiXian <liuzixian4@huawei.com> Signed-off-by: NCheng Jian <cj.chengjian@huawei.com> Reviewed-by: Nwangxiongfeng 00379786 <wangxiongfeng2@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yang Yingliang 提交于
hulk inclusion category: bugfix bugzilla: NA CVE: NA -------------------------------- Enable some configs for test. Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zhang Jian 提交于
ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4JICC CVE: NA ------------------------------------------------- When we access the process's sp_group file and the precess is a kernel process, it's task_struct->mm value will be 0, so we must check it, and make sure the process is not a kernel process. v1->v2: The path of a process as a kernel process is not often triggered, so add a unlikely function to accelerate execytion. Signed-off-by: NZhang Jian <zhangjian210@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 22 11月, 2021 5 次提交
-
-
由 Jan Kara 提交于
stable inclusion from stable-5.10.51 commit 8cc58a6e2c394aa48aa05f600be7d279efbafcd7 bugzilla: 175263 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8cc58a6e2c394aa48aa05f600be7d279efbafcd7 -------------------------------- commit 11c7aa0d upstream. Commit 545fbd07 ("rq-qos: fix missed wake-ups in rq_qos_throttle") tried to fix a problem that a process could be sleeping in rq_qos_wait() without anyone to wake it up. However the fix is not complete and the following can still happen: CPU1 (waiter1) CPU2 (waiter2) CPU3 (waker) rq_qos_wait() rq_qos_wait() acquire_inflight_cb() -> fails acquire_inflight_cb() -> fails completes IOs, inflight decreased prepare_to_wait_exclusive() prepare_to_wait_exclusive() has_sleeper = !wq_has_single_sleeper() -> true as there are two sleepers has_sleeper = !wq_has_single_sleeper() -> true io_schedule() io_schedule() Deadlock as now there's nobody to wakeup the two waiters. The logic automatically blocking when there are already sleepers is really subtle and the only way to make it work reliably is that we check whether there are some waiters in the queue when adding ourselves there. That way, we are guaranteed that at least the first process to enter the wait queue will recheck the waiting condition before going to sleep and thus guarantee forward progress. Fixes: 545fbd07 ("rq-qos: fix missed wake-ups in rq_qos_throttle") CC: stable@vger.kernel.org Signed-off-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210607112613.25344-1-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLihong Kou <koulihong@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zekun Shen 提交于
mainline inclusion from mainline-v5.16-rc2 commit b922f622 category: bugfix bugzilla: NA CVE: CVE-2021-43975 ------------------------------------------------- This bug report shows up when running our research tools. The reports is SOOB read, but it seems SOOB write is also possible a few lines below. In details, fw.len and sw.len are inputs coming from io. A len over the size of self->rpc triggers SOOB. The patch fixes the bugs by adding sanity checks. The bugs are triggerable with compromised/malfunctioning devices. They are potentially exploitable given they first leak up to 0xffff bytes and able to overwrite the region later. The patch is tested with QEMU emulater. This is NOT tested with a real device. Attached is the log we found by fuzzing. BUG: KASAN: slab-out-of-bounds in hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] Read of size 4 at addr ffff888016260b08 by task modprobe/213 CPU: 0 PID: 213 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] __kasan_report.cold+0x37/0x7c ? aq_hw_read_reg_bit+0x60/0x70 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] kasan_report+0xe/0x20 hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] hw_atl_utils_fw_rpc_call+0x95/0x130 [atlantic] hw_atl_utils_fw_rpc_wait+0x176/0x210 [atlantic] hw_atl_utils_mpi_create+0x229/0x2e0 [atlantic] ? hw_atl_utils_fw_rpc_wait+0x210/0x210 [atlantic] ? hw_atl_utils_initfw+0x9f/0x1c8 [atlantic] hw_atl_utils_initfw+0x12a/0x1c8 [atlantic] aq_nic_ndev_register+0x88/0x650 [atlantic] ? aq_nic_ndev_init+0x235/0x3c0 [atlantic] aq_pci_probe+0x731/0x9b0 [atlantic] ? aq_pci_func_init+0xc0/0xc0 [atlantic] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 Reported-by: NBrendan Dolan-Gavitt <brendandg@nyu.edu> Signed-off-by: NZekun Shen <bruceshenzk@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 fengsheng 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IYX7?from=project-issue CVE: NA ------------------------------------------------------------ This driver is not in use. Remove it. Signed-off-by: Nfengsheng <fengsheng5@huawei.com> Reviewed-by: Nlidongming <lidongming5@huawei.com> Reviewed-by: Nouyang delong <ouyangdelong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 fengsheng 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IYWW?from=project-issue CVE: NA ------------------------------------------------------------ This driver is not in use. Remove it. Signed-off-by: Nfengsheng <fengsheng5@huawei.com> Reviewed-by: Nlidongming <lidongming5@huawei.com> Reviewed-by: Nouyang delong <ouyangdelong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 fengsheng 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IYWE?from=project-issue CVE: NA ------------------------------------------------------------ This driver is not in use. Remove it. Signed-off-by: Nfengsheng <fengsheng5@huawei.com> Reviewed-by: Nlidongming <lidongming5@huawei.com> Reviewed-by: Nouyang delong <ouyangdelong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 18 11月, 2021 3 次提交
-
-
由 Xu Jia 提交于
hulk inclusion category: bugfix bugzilla: 177871 CVE: NA ------------------------------------------------- The following warning is falsely reported since commit e2eea86c (ipv4: make exception cache less predictible): error: ‘oldest_p’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *oldest_p = oldest->fnhe_next; ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ net/ipv4/route.c:602:44: note: ‘oldest_p’ was declared here struct fib_nh_exception __rcu **fnhe_p, **oldest_p; Fix and avoid the alarm. Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 zhenwei pi 提交于
stable inclusion from linux-4.19.207 commit aab312696d37de80502ca633b40184de24f22917 -------------------------------- commit f985911b upstream. Hit kernel warning like this, it can be reproduced by verifying 256 bytes datafile by keyctl command, run script: RAWDATA=rawdata SIGDATA=sigdata modprobe pkcs8_key_parser rm -rf *.der *.pem *.pfx rm -rf $RAWDATA dd if=/dev/random of=$RAWDATA bs=256 count=1 openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com" KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \ padd asymmetric 123 @s` keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1 Then the kernel reports: WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x160/0x190 ... Call Trace: public_key_verify_signature+0x282/0x380 ? software_key_query+0x12d/0x180 ? keyctl_pkey_params_get+0xd6/0x130 asymmetric_key_verify_signature+0x66/0x80 keyctl_pkey_verify+0xa5/0x100 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The reason of this issue, in function 'asymmetric_key_verify_signature': '.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value, so use u32 instead of u8 for digest_size field. And reorder struct public_key_signature, it saves 8 bytes on a 64-bit machine. Cc: stable@vger.kernel.org Signed-off-by: Nzhenwei pi <pizhenwei@bytedance.com> Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Nikolay Aleksandrov 提交于
mainline inclusion from mainline-v5.6-rc4 commit 823d81b0 category: bugfix bugzilla: 185773 CVE: NA ------------------------------------------------- In br_dev_xmit() we perform vlan filtering in br_allowed_ingress() but if the packet has the vlan header inside (e.g. bridge with disabled tx-vlan-offload) then the vlan filtering code will use skb_vlan_untag() to extract the vid before filtering which in turn calls pskb_may_pull() and we may end up with a stale eth pointer. Moreover the cached eth header pointer will generally be wrong after that operation. Remove the eth header caching and just use eth_hdr() directly, the compiler does the right thing and calculates it only once so we don't lose anything. Fixes: 057658cb ("bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports") Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NHuang Guobin <huangguobin4@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 17 11月, 2021 1 次提交
-
-
由 Peter Zijlstra 提交于
mainline inclusion from mainline-v5.8-rc1 commit 1c3e5d3f category: feature bugzilla: 175666 CVE: NA --------------------------- Currently entry_64_compat is exempt from objtool, but with vmlinux mode there is no hiding it. Make the following changes to make it pass: - change entry_SYSENTER_compat to STT_NOTYPE; it's not a function and doesn't have function type stack setup. - mark all STT_NOTYPE symbols with UNWIND_HINT_EMPTY; so we do validate them and don't treat them as unreachable. - don't abuse RSP as a temp register, this confuses objtool mightily as it (rightfully) thinks we're doing unspeakable things to the stack. Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NAlexandre Chartre <alexandre.chartre@oracle.com> Acked-by: NAndy Lutomirski <luto@kernel.org> Link: https://lkml.kernel.org/r/20200505134341.272248024@linutronix.deSigned-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Conflicts: arch/x86/entry/entry_64_compat.S [wangshaobo: change ENDPROC to END, avoid objtool skipping STT_FUNC type check] Reviewed-by: NCheng Jian <cj.chengjian@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 15 11月, 2021 2 次提交
-
-
由 Pavel Begunkov 提交于
mainline inclusion from mainline-v5.13-rc2 commit 447c19f3 category: bugfix bugzilla: 185736 CVE: NA ----------------------------------------------- Always remove linked timeout on io_link_timeout_fn() from the master request link list, otherwise we may get use-after-free when first io_link_timeout_fn() puts linked timeout in the fail path, and then will be found and put on master's free. Cc: stable@vger.kernel.org # 5.10+ Fixes: 90cd7e42 ("io_uring: track link timeout's master explicitly") Reported-and-tested-by: syzbot+5a864149dd970b546223@syzkaller.appspotmail.com Signed-off-by: NPavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/69c46bf6ce37fec4fdcd98f0882e18eb07ce693a.1620990121.git.asml.silence@gmail.comSigned-off-by: NJens Axboe <axboe@kernel.dk> conflicts: fs/io_uring.c Signed-off-by: NYe Bin <yebin10@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Zheng Zengkai 提交于
phytium inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I41AUQ -------------------------------------- Disabling CONFIG_ARCH_PHYTIUM results in following compile errors: drivers/iommu/arm-smmu.c: In function ‘phytium_smmu_def_domain_type’: drivers/iommu/arm-smmu.c:1641:6: error: implicit declaration of function ‘typeof_ft2000plus’ [-Werror=implicit-function-declaration] 1641 | if (typeof_ft2000plus() || typeof_s2500()) { | ^~~~~~~~~~~~~~~~~ drivers/iommu/arm-smmu.c:1641:29: error: implicit declaration of function ‘typeof_s2500’ [-Werror=implicit-function-declaration] 1641 | if (typeof_ft2000plus() || typeof_s2500()) { | ^~~~~~~~~~~~ cc1: some warnings being treated as errors Fix it by using CONFIG_ARCH_PHYTIUM to control phytium related code. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 12 11月, 2021 11 次提交
-
-
由 Yu'an Wang 提交于
driver inclusion category: Feature bugzilla: NA CVE: NA In this patch, delete several invalid define and api: 1. sq_head in hisi_qp_status is not used for any judge, as well as qm_sq_head_update 2. crypto hisilicon just support async logic in kernel driver, so hisi_qp_wait logic is abandoned 3. CONFIG_CRYPTO_QM_UACCE seems redundant, so we delete it Signed-off-by: NYu'an Wang <wangyuan46@huawei.com> Reviewed-by: NWeili Qian <qianweili@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yu'an Wang 提交于
driver inclusion category: Bugfix bugzilla: NA CVE: NA Set the flag CRYPTO_TFM_REQ_MAY_BACKLOG in the crypto driver, which can limit task process Signed-off-by: NYu'an Wang <wangyuan46@huawei.com> Reviewed-by: NLongfang Liu <liulongfang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Eric Dumazet 提交于
mainline inclusion from mainline-v5.4-rc2 commit 3256a2d6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4AFRJ?from=project-issue CVE: NA ------------------------------------------------------------ The cited commit exposed an old retransmits_timed_out() bug which assumed it could call tcp_model_timeout() with TCP_RTO_MIN as rto_base for all states. But flows in SYN_SENT or SYN_RECV state uses a different RTO base (1 sec instead of 200 ms, unless BPF choses another value) This caused a reduction of SYN retransmits from 6 to 4 with the default /proc/sys/net/ipv4/tcp_syn_retries value. Fixes: a41e8a88 ("tcp: better handle TCP_USER_TIMEOUT in SYN_SENT state") Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Marek Majkowski <marek@cloudflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Conflicts: net/ipv4/tcp_timer.c Signed-off-by: Jiazhenyuan <jiazhenyuan@uniontech.com> #openEuler_contributor Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yuchung Cheng 提交于
mainline inclusion from mainline-v5.1-rc1 commit 01a523b0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4AFRJ?from=project-issue CVE: NA ------------------------------------------------------------ Create a helper to model TCP exponential backoff for the next patch. This is pure refactor w no behavior change. Signed-off-by: NYuchung Cheng <ycheng@google.com> Signed-off-by: NEric Dumazet <edumazet@google.com> Reviewed-by: NNeal Cardwell <ncardwell@google.com> Reviewed-by: NSoheil Hassas Yeganeh <soheil@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Conflicts: net/ipv4/tcp_timer.c Signed-off-by: Jiazhenyuan <jiazhenyuan@uniontech.com> #openEuler_contributor Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yuchung Cheng 提交于
mainline inclusion from mainline-v5.1-rc1 commit 7ae18975 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4AFRJ?from=project-issue CVE: NA ------------------------------------------------------------ Previously TCP socket's retrans_stamp is not set if the retransmission has failed to send. As a result if a socket is experiencing local issues to retransmit packets, determining when to abort a socket is complicated w/o knowning the starting time of the recovery since retrans_stamp may remain zero. This complication causes sub-optimal behavior that TCP may use the latest, instead of the first, retransmission time to compute the elapsed time of a stalling connection due to local issues. Then TCP may disrecard TCP retries settings and keep retrying until it finally succeed: not a good idea when the local host is already strained. The simple fix is to always timestamp the start of a recovery. It's worth noting that retrans_stamp is also used to compare echo timestamp values to detect spurious recovery. This patch does not break that because retrans_stamp is still later than when the original packet was sent. Signed-off-by: NYuchung Cheng <ycheng@google.com> Signed-off-by: NEric Dumazet <edumazet@google.com> Reviewed-by: NNeal Cardwell <ncardwell@google.com> Reviewed-by: NSoheil Hassas Yeganeh <soheil@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Conflicts: net/ipv4/tcp_timer.c Signed-off-by: Jiazhenyuan <jiazhenyuan@uniontech> #openEuler_contributor Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Pavel Skripkin 提交于
stable inclusion from linux-4.19.208 commit a94a60ef75d6cc2ac4c0d07cd043316e7e8b5b3b -------------------------------- commit 2d186afd upstream. Syzbot reported shift-out-of-bounds bug in profile_init(). The problem was in incorrect prof_shift. Since prof_shift value comes from userspace we need to clamp this value into [0, BITS_PER_LONG -1] boundaries. Second possible shiht-out-of-bounds was found by Tetsuo: sample_step local variable in read_profile() had "unsigned int" type, but prof_shift allows to make a BITS_PER_LONG shift. So, to prevent possible shiht-out-of-bounds sample_step type was changed to "unsigned long". Also, "unsigned short int" will be sufficient for storing [0, BITS_PER_LONG] value, that's why there is no need for "unsigned long" prof_shift. Link: https://lkml.kernel.org/r/20210813140022.5011-1-paskripkin@gmail.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+e68c89a9510c159d9684@syzkaller.appspotmail.com Suggested-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: NPavel Skripkin <paskripkin@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Cyrill Gorcunov 提交于
stable inclusion from linux-4.19.208 commit 6a96bac8ba0a5ab9c9af1ed1c77478e19ae1f0f6 -------------------------------- commit e1fbbd07 upstream. Keno Fischer reported that when a binray loaded via ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to setup brk value because it lays before mm:end_data. For example a test program shows | # ~/t | | start_code 401000 | end_code 401a15 | start_stack 7ffce4577dd0 | start_data 403e10 | end_data 40408c | start_brk b5b000 | sbrk(0) b5b000 and when executed via ld-linux | # /lib64/ld-linux-x86-64.so.2 ~/t | | start_code 7fc25b0a4000 | end_code 7fc25b0c4524 | start_stack 7fffcc6b2400 | start_data 7fc25b0ce4c0 | end_data 7fc25b0cff98 | start_brk 55555710c000 | sbrk(0) 55555710c000 This of course prevent criu from restoring such programs. Looking into how kernel operates with brk/start_brk inside brk() syscall I don't see any problem if we allow to setup brk/start_brk without checking for end_data. Even if someone pass some weird address here on a purpose then the worst possible result will be an unexpected unmapping of existing vma (own vma, since prctl works with the callers memory) but test for RLIMIT_DATA is still valid and a user won't be able to gain more memory in case of expanding VMAs via new values shipped with prctl call. Link: https://lkml.kernel.org/r/20210121221207.GB2174@grain Fixes: bbdc6076 ("binfmt_elf: move brk out of mmap when doing direct loader exec") Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com> Reported-by: NKeno Fischer <keno@juliacomputing.com> Acked-by: NAndrey Vagin <avagin@gmail.com> Tested-by: NAndrey Vagin <avagin@gmail.com> Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Cc: Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Andy Shevchenko 提交于
stable inclusion from linux-4.19.208 commit 523559507138ca4abcf4c2522c0061071c1d60a0 -------------------------------- commit 67db87dc upstream. Currently the CRST parsing relies on the fact that on most of x86 devices the IRQ mapping is 1:1 with Linux vIRQ. However, it may be not true for some. Fix this by converting GSI to Linux vIRQ before checking it. Fixes: ee8209fd ("dma: acpi-dma: parse CSRT to extract additional resources") Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210730202715.24375-1-andriy.shevchenko@linux.intel.comSigned-off-by: NVinod Koul <vkoul@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Li Huafei 提交于
stable inclusion from linux-4.19.208 commit 6cfbbb961bb94de85455fe35140b1350c7ccb76c -------------------------------- The commit 960434acef37 ("tracing/kprobe: Fix to support kretprobe events on unloaded modules") backport from v5.11, which modifies the return value of kprobe_on_func_entry(). However, there is no adaptation modification in create_trace_kprobe(), resulting in the exact opposite behavior. Now we need to return an error immediately only if kprobe_on_func_entry() returns -EINVAL. Fixes: 960434acef37 ("tracing/kprobe: Fix to support kretprobe events on unloaded modules") Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Neeraj Upadhyay 提交于
stable inclusion from linux-4.19.208 commit 3226fb90cf5dc89611f742f122a33d4598076ad5 -------------------------------- commit fd6bc19d upstream. Tasks waiting within exp_funnel_lock() for an expedited grace period to elapse can be starved due to the following sequence of events: 1. Tasks A and B both attempt to start an expedited grace period at about the same time. This grace period will have completed when the lower four bits of the rcu_state structure's ->expedited_sequence field are 0b'0100', for example, when the initial value of this counter is zero. Task A wins, and thus does the actual work of starting the grace period, including acquiring the rcu_state structure's .exp_mutex and sets the counter to 0b'0001'. 2. Because task B lost the race to start the grace period, it waits on ->expedited_sequence to reach 0b'0100' inside of exp_funnel_lock(). This task therefore blocks on the rcu_node structure's ->exp_wq[1] field, keeping in mind that the end-of-grace-period value of ->expedited_sequence (0b'0100') is shifted down two bits before indexing the ->exp_wq[] field. 3. Task C attempts to start another expedited grace period, but blocks on ->exp_mutex, which is still held by Task A. 4. The aforementioned expedited grace period completes, so that ->expedited_sequence now has the value 0b'0100'. A kworker task therefore acquires the rcu_state structure's ->exp_wake_mutex and starts awakening any tasks waiting for this grace period. 5. One of the first tasks awakened happens to be Task A. Task A therefore releases the rcu_state structure's ->exp_mutex, which allows Task C to start the next expedited grace period, which causes the lower four bits of the rcu_state structure's ->expedited_sequence field to become 0b'0101'. 6. Task C's expedited grace period completes, so that the lower four bits of the rcu_state structure's ->expedited_sequence field now become 0b'1000'. 7. The kworker task from step 4 above continues its wakeups. Unfortunately, the wake_up_all() refetches the rcu_state structure's .expedited_sequence field: wake_up_all(&rnp->exp_wq[rcu_seq_ctr(rcu_state.expedited_sequence) & 0x3]); This results in the wakeup being applied to the rcu_node structure's ->exp_wq[2] field, which is unfortunate given that Task B is instead waiting on ->exp_wq[1]. On a busy system, no harm is done (or at least no permanent harm is done). Some later expedited grace period will redo the wakeup. But on a quiet system, such as many embedded systems, it might be a good long time before there was another expedited grace period. On such embedded systems, this situation could therefore result in a system hang. This issue manifested as DPM device timeout during suspend (which usually qualifies as a quiet time) due to a SCSI device being stuck in _synchronize_rcu_expedited(), with the following stack trace: schedule() synchronize_rcu_expedited() synchronize_rcu() scsi_device_quiesce() scsi_bus_suspend() dpm_run_callback() __device_suspend() This commit therefore prevents such delays, timeouts, and hangs by making rcu_exp_wait_wake() use its "s" argument consistently instead of refetching from rcu_state.expedited_sequence. Fixes: 3b5f668e ("rcu: Overlap wakeups with next expedited grace period") Signed-off-by: NNeeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by: NPaul E. McKenney <paulmck@kernel.org> Signed-off-by: NDavid Chen <david.chen@nutanix.com> Acked-by: NNeeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Benjamin Hesmans 提交于
stable inclusion from linux-4.19.207 commit d6efada330af09253b0f81a0d836cee02192bd4f -------------------------------- [ Upstream commit 730affed ] Bug reported by KASAN: BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) Call Trace: (...) inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) (...) nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91 net/ipv6/netfilter/nf_socket_ipv6.c:146) It seems that this bug has already been fixed by Eric Dumazet in the past in: commit 78296c97 ("netfilter: xt_socket: fix a stack corruption bug") But a variant of the same issue has been introduced in commit d64d80a2 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") `daddr` and `saddr` potentially hold a reference to ipv6_var that is no longer in scope when the call to `nf_socket_get_sock_v6` is made. Fixes: d64d80a2 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") Acked-by: NMatthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: NBenjamin Hesmans <benjamin.hesmans@tessares.net> Reviewed-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-