- 27 9月, 2022 1 次提交
-
-
由 Like Xu 提交于
mainline inclusion from mainline-v5.4 commit 3ca270fc category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5SDUS CVE: NA ------------- Currently, perf_event_period() is used by user tools via ioctl. Based on naming convention, exporting perf_event_period() for kernel users (such as KVM) who may recalibrate the event period for their assigned counter according to their requirements. The perf_event_period() is an external accessor, just like the perf_event_{en,dis}able() and should thus use perf_event_ctx_lock(). Suggested-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NLike Xu <like.xu@linux.intel.com> Acked-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NYanan Wang <wangyanan55@huawei.com> Reviewed-by: NZenghui Yu <yuzenghui@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
- 07 9月, 2022 1 次提交
-
-
由 Dan Carpenter 提交于
stable inclusion from stable-v4.19.256 commit 2cff35bb4573cbdbf1e0a405539dc9680004abe8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q0SQ CVE: NA -------------------------------- [ Upstream commit 045ed31e ] The kfifo_to_user() macro is supposed to return zero for success or negative error codes. Unfortunately, there is a signedness bug so it returns unsigned int. This only affects callers which try to save the result in ssize_t and as far as I can see the only place which does that is line6_hwdep_read(). TL;DR: s/_uint/_int/. Link: https://lkml.kernel.org/r/YrVL3OJVLlNhIMFs@kili Fixes: 144ecf31 ("kfifo: fix kfifo_alloc() to return a signed int value") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Cc: Stefani Seibold <stefani@seibold.net> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 29 8月, 2022 2 次提交
-
-
由 Jiri Slaby 提交于
stable inclusion from stable-v4.19.254 commit eb059bf8c237fe41fbaed4a6cccacce687b83222 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 -------------------------------- commit a501ab75 upstream. There is a race in pty_write(). pty_write() can be called in parallel with e.g. ioctl(TIOCSTI) or ioctl(TCXONC) which also inserts chars to the buffer. Provided, tty_flip_buffer_push() in pty_write() is called outside the lock, it can commit inconsistent tail. This can lead to out of bounds writes and other issues. See the Link below. To fix this, we have to introduce a new helper called tty_insert_flip_string_and_push_buffer(). It does both tty_insert_flip_string() and tty_flip_buffer_commit() under the port lock. It also calls queue_work(), but outside the lock. See 71a174b3 (pty: do tty_flip_buffer_push without port->lock in pty_write) for the reasons. Keep the helper internal-only (in drivers' tty.h). It is not intended to be used widely. Link: https://seclists.org/oss-sec/2022/q2/155 Fixes: 71a174b3 (pty: do tty_flip_buffer_push without port->lock in pty_write) Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: NHillf Danton <hdanton@sina.com> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> conflict: drivers/tty/pty.c Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v4.19.254 commit 3ca62328d9bfaa597397099cb7f5a485a9bebacc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 -------------------------------- commit 5db96ef2 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). All users were converted in the previous patches, so remove tty_schedule_flip() completely while inlining its body into tty_flip_buffer_push(). One less exported function. Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-4-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 01 8月, 2022 1 次提交
-
-
由 Helge Deller 提交于
mainline inclusion from mainline-v5.19-rc6 commit e64242ca category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5IQ4M CVE: CVE-2021-33655 -------------------------------- 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: NChen Jun <chenjun102@huawei.com> Conflicts: drivers/video/fbdev/core/fbcon.c drivers/video/fbdev/core/fbmem.c include/linux/fbcon.h Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 28 7月, 2022 1 次提交
-
-
由 Jan Kara 提交于
hulk inclusion category: bugfix bugzilla: 186975, https://gitee.com/openeuler/kernel/issues/I5HT6F CVE: NA Reference: https://patchwork.ozlabs.org/project/linux-ext4/list/?series=309169 -------------------------------- Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused - mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by: NJan Kara <jack@suse.cz> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 22 7月, 2022 1 次提交
-
-
由 Zhengchao Shao 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5HWKR CVE: NA -------------------------------- Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5 LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Conflict: net/bpf/test_run.c 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> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 21 7月, 2022 3 次提交
-
-
由 Hui Tang 提交于
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Signed-off-by: NHui Tang <tanghui20@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Hui Tang 提交于
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Compare taskgroup 'util_avg' in perferred cpu with capacity preferred cpu, dynamicly adjust cpu range for task wakeup process. Signed-off-by: NHui Tang <tanghui20@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Hui Tang 提交于
hulk inclusion category: feature bugzilla: 187173, https://gitee.com/openeuler/kernel/issues/I5G4IH CVE: NA -------------------------------- Add 'prefer_cpus' sysfs and related interface in cgroup cpuset. Signed-off-by: NHui Tang <tanghui20@huawei.com> Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 14 7月, 2022 3 次提交
-
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit b6113052. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit b2f0e44f. Because it will introduce following problem in ltp zram tests: BUG: unable to handle kernel NULL pointer dereference at 0000000000000600 PGD 0 P4D 0 Oops: 0002 [#1] SMP PTI CPU: 28 PID: 172121 Comm: sh Kdump: loaded Tainted: G OE --------- - - 4.18.0+ #2 Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 5.15 05/21/2019 RIP: 0010:flush_disk+0x1d/0x50 RSP: 0018:ffffaf14a516fe20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff899e26bac380 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff899e26bac380 RBP: ffff899e26bac380 R08: 00000000000006a9 R09: 0000000000000004 R10: ffff89cd878ff440 R11: 0000000000000001 R12: 0000000000000000 R13: ffff899e26bac398 R14: ffffaf14a516ff00 R15: ffff89cd8709c3e0 FS: 00007f78d6840740(0000) GS:ffff89fcbf480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000600 CR3: 000000308afc0002 CR4: 00000000001606e0 Call Trace: revalidate_disk+0x57/0x80 reset_store+0xaf/0x120 [zram] kernfs_fop_write+0x10f/0x190 vfs_write+0xad/0x1a0 ksys_write+0x52/0xc0 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca This is because "bdev->bd_disk" is not ensured to exist, just convert "set_bit(BDEV_NEED_PART_SCAN, &bdev->bd_flags)" to "set_bit(GD_NEED_PART_SCAN, &bdev->bd_disk->state)" is wrong. The reason to backport it is that commit 2a57456c8973 ("block: Fix warning in bd_link_disk_holder()") has a regression that part scan is disabled in device_add_disk(), and this problem will be fixed in later patch. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 187190, https://gitee.com/src-openeuler/kernel/issues/I5GWOV CVE: NA -------------------------------- This reverts commit 64ba823f. The patches that broke kabi will be reverted together. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 13 7月, 2022 1 次提交
-
-
由 Jiri Slaby 提交于
stable inclusion from stable-4.19.250 commit b15d5731b708a2190fec836990b8aefbbf36b07a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5GKVX CVE: CVE-2021-33656 -------------------------------- commit ff2047fb upstream. Drop support for these ioctls: * PIO_FONT, PIO_FONTX * GIO_FONT, GIO_FONTX * PIO_FONTRESET As was demonstrated by commit 90bfdeef (tty: make FONTX ioctl use the tty pointer they were actually passed), these ioctls are not used from userspace, as: 1) they used to be broken (set up font on current console, not the open one) and racy (before the commit above) 2) KDFONTOP ioctl is used for years instead Note that PIO_FONTRESET is defunct on most systems as VGA_CONSOLE is set on them for ages. That turns on BROKEN_GRAPHICS_PROGRAMS which makes PIO_FONTRESET just return an error. We are removing KD_FONT_FLAG_OLD here as it was used only by these removed ioctls. kd.h header exists both in kernel and uapi headers, so we can remove the kernel one completely. Everyone includeing kd.h will now automatically get the uapi one. There are now unused definitions of the ioctl numbers and "struct consolefontdesc" in kd.h, but as it is a uapi header, I am not touching these. Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210105120239.28031-8-jslaby@suse.cz Cc: guodaxing <guodaxing@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 08 7月, 2022 3 次提交
-
-
由 Luo Meng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA -------------------------------- Because add state in gendisk and remove flags in block_device, to fix the kabi chage. Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.10-rc1 commit 38430f08 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA ------------------------------------------------- We can only scan for partitions on the whole disk, so move the flag from struct block_device to struct gendisk. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflicts: block/genhd.c drivers/ide/ide-gd.c fs/block_dev.c include/linux/blk_types.h Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.10-rc1 commit f4ad06f2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETAB CVE: NA ------------------------------------------------- Replace bd_invalidate with a new BDEV_NEED_PART_SCAN flag in a bd_flags variable to better describe the condition. Signed-off-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJosef Bacik <josef@toxicpanda.com> Reviewed-by: NJohannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflicts: fs/block_dev.c include/linux/blk_types.h Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com>
-
- 06 7月, 2022 3 次提交
-
-
由 Pawan Gupta 提交于
stable inclusion from stable-v4.19.248 commit f2983fbba1cccac611d4966277f0336374fad0be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5D5RS CVE: CVE-2022-21123,CVE-2022-21125,CVE-2022-21166 -------------------------------- commit 8d50cdf8 upstream Add the sysfs reporting file for Processor MMIO Stale Data vulnerability. It exposes the vulnerability and mitigation state similar to the existing files for the other hardware vulnerabilities. Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYipeng Zou <zouyipeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Guenter Roeck 提交于
stable inclusion from stable-v4.19.248 commit 813bb0c45460e58ab8829d0aa5ea6f42eba4461a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5D5RS CVE: CVE-2022-21123,CVE-2022-21125,CVE-2022-21166 -------------------------------- commit 2accfa69 upstream. 0-day is not happy that there is no prototype for cpu_show_srbds(): drivers/base/cpu.c:565:16: error: no previous prototype for 'cpu_show_srbds' Fixes: 7e5b3c26 ("x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation") Reported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20200617141410.93338-1-linux@roeck-us.netSigned-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYipeng Zou <zouyipeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Konstantin Khlebnikov 提交于
mainline inclusion from mainline-v5.7-rc1 commit 2b8bd423 category: bugfix bugzilla: 187044, https://gitee.com/openeuler/kernel/issues/I5F2BY CVE: NA -------------------------------- Currently io_ticks is approximated by adding one at each start and end of requests if jiffies counter has changed. This works perfectly for requests shorter than a jiffy or if one of requests starts/ends at each jiffy. If disk executes just one request at a time and they are longer than two jiffies then only first and last jiffies will be accounted. Fix is simple: at the end of request add up into io_ticks jiffies passed since last update rather than just one jiffy. Example: common HDD executes random read 4k requests around 12ms. fio --name=test --filename=/dev/sdb --rw=randread --direct=1 --runtime=30 & iostat -x 10 sdb Note changes of iostat's "%util" 8,43% -> 99,99% before/after patch: Before: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 82,60 0,00 330,40 0,00 8,00 0,96 12,09 12,09 0,00 1,02 8,43 After: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 82,50 0,00 330,00 0,00 8,00 1,00 12,10 12,10 0,00 12,12 99,99 Now io_ticks does not loose time between start and end of requests, but for queue-depth > 1 some I/O time between adjacent starts might be lost. For load estimation "%util" is not as useful as average queue length, but it clearly shows how often disk queue is completely empty. Fixes: 5b18b5a7 ("block: delete part_round_stats and switch to less precise counting") Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Reviewed-by: NMing Lei <ming.lei@redhat.com> Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflict: block/bio.c block/blk-core.c include/linux/genhd.h Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 01 7月, 2022 1 次提交
-
-
由 Steven Rostedt (VMware) 提交于
stable inclusion from stable-5.10.50 commit 0531e84bc8ac750b7a15c18d478804c0d98f0a86 bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETW1 CVE: NA -------------------------------- commit 9913d574 upstream. All internal use cases for tracepoint_probe_register() is set to not ever be called with the same function and data. If it is, it is considered a bug, as that means the accounting of handling tracepoints is corrupted. If the function and data for a tracepoint is already registered when tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and return with EEXISTS. The BPF system call can end up calling tracepoint_probe_register() with the same data, which now means that this can trigger the warning because of a user space process. As WARN_ON_ONCE() should not be called because user space called a system call with bad data, there needs to be a way to register a tracepoint without triggering a warning. Enter tracepoint_probe_register_may_exist(), which can be called, but will not cause a WARN_ON() if the probe already exists. It will still error out with EEXIST, which will then be sent to the user space that performed the BPF system call. This keeps the previous testing for issues with other users of the tracepoint code, while letting BPF call it with duplicated data and not warn about it. Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/ Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153 Cc: stable@vger.kernel.org Fixes: c4f6699d ("bpf: introduce BPF_RAW_TRACEPOINT") Reported-by: Nsyzbot <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com> Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: syzbot+721aa903751db87aa244@syzkaller.appspotmail.com Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 29 6月, 2022 6 次提交
-
-
由 Wang Wensheng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- When SPG_NOD_DVPP is specified to sp_group_add_task, we don't create a DVPP mapping for the newly created sp_group. And the new group cannot support allocating DVPP memory. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Wang Wensheng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- 1. Add a list for sp_mapping to record all the sp_groups attached to it. 2. Initialize the sp_mapping for local_group when it is created. So when we add a task to a group, we should merge the dvpp mapping of the local group. 3. Every two groups can be merged if and only if at least one of them is empty. Then the empty mapping would be dropped and another mapping would be attached to the two groups. This need to traverse all the groups attached to the mapping. 4. A mapping is considered empty when no spa is allocated from it and its address space is default. Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- The address space of the DVPP is managed by group. When releasing the shared pool memory, you need to find the corresponding address space based on the ID. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- The DVPP address space is per process or per sharing group. During sp_free and unshare, you need to know which address space the current address belongs to. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- Separately manage the normal and dvpp address spaces of the sp_group and set the normal and dvpp address spaces of the corresponding groups when adding a group, sp_alloc, and k2task. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhou Guanghui 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5EORS CVE: NA -------------------------------- struct sp_mapping is used to manage the address space of a shared pool. During the initialization of the shared pool, normal address spaces are created to allocate the memory of the current shared pool. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 21 6月, 2022 1 次提交
-
-
由 Joe Perches 提交于
mainline inclusion from mainline-v5.10-rc1 commit 7981593b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5C32F CVE: CVE-2022-20166 -------------------------------------------------- Convert the unbound sprintf in hugetlb_report_node_meminfo to use sysfs_emit_at so that no possible overrun of a PAGE_SIZE buf can occur. Signed-off-by: NJoe Perches <joe@perches.com> Acked-by: NMike Kravetz <mike.kravetz@oracle.com> Link: https://lore.kernel.org/r/894b351b82da6013cde7f36ff4b5493cd0ec30d0.1600285923.git.joe@perches.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: drivers/base/node.c include/linux/hugetlb.h Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 15 6月, 2022 2 次提交
-
-
由 Zhang Qiao 提交于
hulk inclusion category: bugfix bugzilla: 186973, https://gitee.com/openeuler/kernel/issues/I5CA6K CVE: NA -------------------------------- This reverts commit 74bd9b82. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Zhang Qiao 提交于
hulk inclusion category: bugfix bugzilla: 186973, https://gitee.com/openeuler/kernel/issues/I5CA6K CVE: NA -------------------------------- This reverts commit af98db5f. the patch af98db5f("sched: Fix yet more sched_fork()") may be cause a process sleep at cgroup_post_fork()->freezer_fork() while taking group_threadgroup_rwsem lock long time, it cause a problem that other tasks will wait while fork child process and the system will stall. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 14 6月, 2022 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
stable inclusion from linux-4.19.221 commit b1efa723b986a84f84a95b6907cffe3a357338c9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5BTIG CVE: CVE-2022-20132 -------------------------------- commit f83baa0c upstream. A number of HID drivers already call hid_is_using_ll_driver() but only for the detection of if this is a USB device or not. Make this more obvious by creating hid_is_usb() and calling the function that way. Also converts the existing hid_is_using_ll_driver() functions to use the new call. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NRui Xiang <rui.xiang@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 02 6月, 2022 5 次提交
-
-
由 Tariq Toukan 提交于
stable inclusion from stable-4.19.244 commit 48fed355543418c34de4b521365f438041523a1d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5A6BA CVE: NA -------------------------------- [ Upstream commit 85db6352 ] The find_next_netdev_feature() macro gets the "remaining length", not bit index. Passing "bit - 1" for the following iteration is wrong as it skips the adjacent bit. Pass "bit" instead. Fixes: 3b89ea9c ("net: Fix for_each_netdev_feature on Big endian") Signed-off-by: NTariq Toukan <tariqt@nvidia.com> Reviewed-by: NGal Pressman <gal@nvidia.com> Link: https://lore.kernel.org/r/20220504080914.1918-1-tariqt@nvidia.comSigned-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Kees Cook 提交于
stable inclusion from stable-4.19.240 commit 116a890119da05fe05dab301c921794ba6b61271 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5A6BA CVE: NA -------------------------------- commit 2618a0da upstream. With GCC 12, -Wstringop-overread was warning about an implicit cast from char[6] to char[8]. However, the extra 2 bytes are always thrown away, alignment doesn't matter, and the risk of hitting the edge of unallocated memory has been accepted, so this prototype can just be converted to a regular char *. Silences: net/core/dev.c: In function ‘bpf_prog_run_generic_xdp’: net/core/dev.c:4618:21: warning: ‘ether_addr_equal_64bits’ reading 8 bytes from a region of size 6 [-Wstringop-overread] 4618 | orig_host = ether_addr_equal_64bits(eth->h_dest, > skb->dev->dev_addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/core/dev.c:4618:21: note: referencing argument 1 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’} net/core/dev.c:4618:21: note: referencing argument 2 of type ‘const u8[8]’ {aka ‘const unsigned char[8]’} In file included from net/core/dev.c:91: include/linux/etherdevice.h:375:20: note: in a call to function ‘ether_addr_equal_64bits’ 375 | static inline bool ether_addr_equal_64bits(const u8 addr1[6+2], | ^~~~~~~~~~~~~~~~~~~~~~~ Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de> Tested-by: NMarc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/netdev/20220212090811.uuzk6d76agw2vv73@pengutronix.de Cc: Jakub Kicinski <kuba@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Cc: Khem Raj <raj.khem@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Waiman Long 提交于
stable inclusion from stable-4.19.238 commit ff929e3abef16c409a9beef08bcc29ab940d0ce6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5A6BA CVE: NA -------------------------------- commit a431dbbc upstream. The gcc 12 compiler reports a "'mem_section' will never be NULL" warning on the following code: static inline struct mem_section *__nr_to_section(unsigned long nr) { #ifdef CONFIG_SPARSEMEM_EXTREME if (!mem_section) return NULL; #endif if (!mem_section[SECTION_NR_TO_ROOT(nr)]) return NULL; : It happens with CONFIG_SPARSEMEM_EXTREME off. The mem_section definition is #ifdef CONFIG_SPARSEMEM_EXTREME extern struct mem_section **mem_section; #else extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; #endif In the !CONFIG_SPARSEMEM_EXTREME case, mem_section is a static 2-dimensional array and so the check "!mem_section[SECTION_NR_TO_ROOT(nr)]" doesn't make sense. Fix this warning by moving the "!mem_section[SECTION_NR_TO_ROOT(nr)]" check up inside the CONFIG_SPARSEMEM_EXTREME block and adding an explicit NR_SECTION_ROOTS check to make sure that there is no out-of-bound array access. Link: https://lkml.kernel.org/r/20220331180246.2746210-1-longman@redhat.com Fixes: 3e347261 ("sparsemem extreme implementation") Signed-off-by: NWaiman Long <longman@redhat.com> Reported-by: NJustin Forbes <jforbes@redhat.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rafael Aquini <aquini@redhat.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: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 NeilBrown 提交于
stable inclusion from stable-4.19.238 commit 2615cdae1daac1f1548394a5843252cac1049b6c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5A6BA CVE: NA -------------------------------- [ Upstream commit 64158668 ] 1/ Taking the i_rwsem for swap IO triggers lockdep warnings regarding possible deadlocks with "fs_reclaim". These deadlocks could, I believe, eventuate if a buffered read on the swapfile was attempted. We don't need coherence with the page cache for a swap file, and buffered writes are forbidden anyway. There is no other need for i_rwsem during direct IO. So never take it for swap_rw() 2/ generic_write_checks() explicitly forbids writes to swap, and performs checks that are not needed for swap. So bypass it for swap_rw(). Signed-off-by: NNeilBrown <neilb@suse.de> Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-4.19.238 commit 3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5A6BA CVE: NA -------------------------------- commit 23a9dbbe upstream. On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow. Cc: stable@vger.kernel.org Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NChuck Lever <chuck.lever@oracle.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 24 5月, 2022 1 次提交
-
-
由 Tong Tiangen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I591O4 CVE: NA -------------------------------- This patch add uce kernel recovery path support in coredump process. Coredump file writing to fs is related to the specific implementation of fs's write_iter operation. This patch only supports uce kernel recovery in ext4/tmpfs/pipefs. Coredump scenario use bit4 of uce_kernel_recover as the switch which can be set in procfs and cmdline. Signed-off-by: NTong Tiangen <tongtiangen@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 23 5月, 2022 1 次提交
-
-
由 Zhang Qiao 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZJT CVE: NA -------------------------------- Before, when detect the cpu is overloaded, we throttle offline tasks at exit_to_user_mode_loop() before returning to user mode. Some architects(e.g.,arm64) do not support QOS scheduler because a task do not via exit_to_user_mode_loop() return to userspace at these platforms. In order to slove this problem and support qos scheduler on all architectures, if we require throttling offline tasks, we set flag TIF_NOTIFY_RESUME to an offline task when it is picked and throttle it at tracehook_notify_resume(). Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 17 5月, 2022 1 次提交
-
-
由 Trond Myklebust 提交于
mainline inclusion from mainline-v5.18-rc7 commit fd13359f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I57MRF CVE: NA ------------------------------------------- Ensure that the gssproxy client connects to the server from the gssproxy daemon process context so that the AF_LOCAL socket connection is done using the correct path and namespaces. Fixes: 1d658336 ("SUNRPC: Add RPC based upcall mechanism for RPCGSS auth") Cc: stable@vger.kernel.org Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> conflicts: include/linux/sunrpc/clnt.h net/sunrpc/clnt.c Signed-off-by: NWang Hai <wanghai38@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-
- 13 5月, 2022 1 次提交
-
-
由 Zhou Guanghui 提交于
ascend inclusion category: Bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I578LV CVE: NA -------------------------------- When the driver uses the shared pool memory to share the memory with the user space, the user space is not allowed to operate this area. This prevents users from damaging sensitive data. When the sp_alloc and k2u processes apply for private memory, read-only memory can be applied for. Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
-