- 09 9月, 2022 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhengzengkai Some BPF programs compiled on s390 fail to load, because s390 arch-specific linux headers contain float and double types. Introduce support for such types by representing them using the new BTF_KIND_FLOAT. This series deals with libbpf, bpftool, in-kernel BTF parser as well as selftests and documentation. Link:https://gitee.com/openeuler/kernel/pulls/108 Reviewed-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @x56Jason This PR is to enable IPI virtualization support for Intel SPR. ## Intel-Kernel Issue #I5ODSC ## Test Use IPI benchmark (https://lore.kernel.org/kvm/20171219085010.4081-1-ynorov@caviumnetworks.com) to do unicast IPI testing ("Normal IPI" case in the benchmark): - With host disabled IPI virtualization, and guest enable x2apic mode, we can see a lot of MSR_WR_VMEXITs - With host enabled IPI virtualization, and guest enable x2apic mode, MSR_WR_VMEXITs from the benchmark disappears. - Comparing host disabled IPIv vs. host enabled IPIv, the IPIv enabled case takes shorter time to do the IPI. With IPIv enabled: ``` [ 517.422480] Normal IPI: 203214459, 237340464 ns [ 518.467208] Normal IPI: 203531652, 237656950 ns [ 519.508544] Normal IPI: 210828433, 269128255 ns [ 520.545573] Normal IPI: 219237071, 257442791 ns [ 521.632722] Normal IPI: 222442577, 264457837 ns [ 522.680563] Normal IPI: 214068805, 264828652 ns [ 523.716551] Normal IPI: 206517521, 246817681 ns [ 524.745078] Normal IPI: 216683548, 264798480 ns [ 525.718962] Normal IPI: 207031786, 250300553 ns [ 526.861676] Normal IPI: 296051188, 342197017 ns ``` With IPIv disabled: ``` [ 218.838522] Normal IPI: 268385248, 331187170 ns [ 219.865669] Normal IPI: 277581839, 335817862 ns [ 220.906605] Normal IPI: 302618152, 374527951 ns [ 221.914170] Normal IPI: 270566994, 334971550 ns [ 222.965606] Normal IPI: 284867960, 362923781 ns [ 224.077227] Normal IPI: 346076611, 425008936 ns [ 225.087076] Normal IPI: 306762251, 364504064 ns [ 226.283219] Normal IPI: 385979433, 456133361 ns [ 227.359055] Normal IPI: 281473772, 363612958 ns [ 228.423180] Normal IPI: 297768236, 371935725 ns ``` ## Known Issue N/A ## Default Config Change N/A Link:https://gitee.com/openeuler/kernel/pulls/96 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: Liu Chao <liuchao173@huawei.com> Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @haochengxie This PR includes minimum essential patches to enable AMD EPYC Genoa platform. ### Issue Enable AMD EPYC Genoa platform support for openEuler https://gitee.com/openeuler/kernel/issues/I5NGRU ### Backporting Patches included crypto: 3438de03 5.15 crypto: ccp - Add support for new CCP/PSP device ID hwmon: 2ade8fc6 5.14 x86/amd_nb: Add AMD family 19h model 50h PCI ids (front patch) c8d0d3fa 5.12 hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support(front patch) 02c9dce4 5.15 hwmon: (k10temp) support Zen3 APUs 128066c8 5.15 hwmon: (k10temp) Add additional missing Zen2 and Zen3 APUs 02a2484c 5.15 hwmon: (k10temp) Don't show Tdie for all Zen/Zen2/Zen3 CPU/APU 0e3f52bb 5.15 hwmon: (k10temp) Rework the temperature offset calculation 25572c81 5.15 hwmon: (k10temp) Add support for yellow carp 23c69b90 5.15 hwmon: (k10temp) Remove residues of current and voltage f707bcb5 5.17 hwmon: (k10temp) Remove unused definitions 4fb0abfe 5.17 x86/amd_nb: Add AMD Family 19h Models (10h-1Fh) and (A0h-AFh) PCI IDs 3cf90efa 5.17 hwmon: (k10temp) Add support for AMD Family 19h Models 10h-1Fh and A0h-AFh 8bb050cd 5.17 hwmon: (k10temp) Support up to 12 CCDs on AMD Family of processors EDAC: f9571124 5.17 EDAC: Add RDDR5 and LRDDR5 memory types e2be5955 5.17 EDAC/amd64: Add support for AMD Family 19h Models 10h-1Fh and A0h-AFh 75aeaaf2 5.18 EDAC/amd64: Set memory type per DIMM 2151c84e 5.18 EDAC/amd64: Add new register offset support and related changes MCE: 94a311ce 5.14 x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank types 5176a93a 5.17 x86/MCE/AMD, EDAC/mce_amd: Add new SMCA bank types f38ce910 5.16 x86/MCE/AMD: Export smca_get_bank_type symbol 0b746e8c 5.17 x86/MCE/AMD, EDAC/amd64: Move address translation to AMD64 EDAC 91f75eb4 5.17 x86/MCE/AMD, EDAC/mce_amd: Support non-uniform MCA bank type enumeration kvm Essential: 03ca4589 5.13 KVM: x86: Prevent KVM SVM from loading on kernels with 5-level paging 43e540cc 5.15 KVM: SVM: Add 5-level page table support for SVM cb0f722a 5.15 KVM: x86/mmu: Support shadowing NPT when 5-level paging is enabled 39150352 5.17 KVM: x86: SVM: move avic definitions from AMD's spec to svm.h 4a204f78 5.18-rc1 KVM: SVM: Allow AVIC support on system w/ physical APIC ID > 255 Link:https://gitee.com/openeuler/kernel/pulls/98 Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 08 9月, 2022 6 次提交
-
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit 6be6a0ba category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6be6a0baffc1357b6d2023155753f111624c4fec ------------------------------------------------- Also document the expansion of the kind bitfield. Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210226202256.116518-11-iii@linux.ibm.com (cherry picked from commit 6be6a0ba) Signed-off-by: NWang Yufen <wangyufen@huawei.com> Conflicts: Documentation/bpf/btf.rst
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit 7999cf7d category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7999cf7df899caf244236dcc11cce844347dab4a ------------------------------------------------- Check that floats don't interfere with struct deduplication, that they are not merged with another kinds and that floats of different sizes are not merged with each other. Suggested-by: NAndrii Nakryiko <andrii@kernel.org> Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210226202256.116518-9-iii@linux.ibm.com (cherry picked from commit 7999cf7d) Signed-off-by: NWang Yufen <wangyufen@huawei.com>
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit 7e72aad3 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e72aad3a15c06e40e3ccd2352e5010e978f1acf ------------------------------------------------- Test the good variants as well as the potential malformed ones. Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210226202256.116518-8-iii@linux.ibm.com (cherry picked from commit 7e72aad3) Signed-off-by: NWang Yufen <wangyufen@huawei.com>
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit b1828f0b category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1828f0b04828aa8cccadf00a702f459caefeed9 ------------------------------------------------- On the kernel side, introduce a new btf_kind_operations. It is similar to that of BTF_KIND_INT, however, it does not need to handle encodings and bit offsets. Do not implement printing, since the kernel does not know how to format floating-point values. Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210226202256.116518-7-iii@linux.ibm.com (cherry picked from commit b1828f0b) Signed-off-by: NWang Yufen <wangyufen@huawei.com> Conflicts: kernel/bpf/btf.c
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit eea154a8 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eea154a852e827c003215f7beed3e10f05471a86 ------------------------------------------------- The bit being checked by this test is no longer reserved after introducing BTF_KIND_FLOAT, so use the next one instead. Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210226202256.116518-6-iii@linux.ibm.com (cherry picked from commit eea154a8) Signed-off-by: NWang Yufen <wangyufen@huawei.com>
-
由 Ilya Leoshkevich 提交于
mainline inclusion from mainline-5.13-rc1 commit 737e0f91 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5Q927 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=737e0f919a8d2a313618d8ac67d50e8223bc5d74 ------------------------------------------------- Only dumping support needs to be adjusted, the code structure follows that of BTF_KIND_INT. Example plain and JSON outputs: [4] FLOAT 'float' size=4 {"id":4,"kind":"FLOAT","name":"float","size":4} Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210226202256.116518-5-iii@linux.ibm.com (cherry picked from commit 737e0f91) Signed-off-by: NWang Yufen <wangyufen@huawei.com> Conflicts: tools/bpf/bpftool/btf.c
-
- 06 9月, 2022 14 次提交
-
-
由 Pu Lehui 提交于
mainline inclusion from mainline-v6.0-rc4 commit 7d6620f1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5POF1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d6620f107bae6ed687ff07668e8e8f855487aa9 -------------------------------- Syzkaller reported a triggered kernel BUG as follows: ------------[ cut here ]------------ kernel BUG at kernel/bpf/cgroup.c:925! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e4 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 8b 0c5 RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Call Trace: <TASK> cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Repetition steps: For the following cgroup tree, root | cg1 | cg2 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs attach type is NONE or OVERRIDE. 2. write 1 to /proc/thread-self/fail-nth for failslab. 3. detach prog1 for cg1, and then kernel BUG occur. Failslab injection will cause kmalloc fail and fall back to purge_effective_progs. The problem is that cg2 have attached another prog, so when go through cg2 layer, iteration will add pos to 1, and subsequent operations will be skipped by the following condition, and cg will meet NULL in the end. `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` The NULL cg means no link or prog match, this is as expected, and it's not a bug. So here just skip the no match situation. Fixes: 4c46091e ("bpf: Fix KASAN use-after-free Read in compute_effective_progs") Signed-off-by: NPu Lehui <pulehui@huawei.com> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220813134030.1972696-1-pulehui@huawei.comReviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Daniel Borkmann 提交于
mainline inclusion from mainline-v6.0-rc4 commit a657182a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5PNIO CVE: CVE-2022-2905 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a657182a5c5150cdfacb6640aad1d2712571a409 -------------------------------- Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d The problem here is that a range of tnum_range(0, map->max_entries - 1) has limited ability to represent the concrete tight range with the tnum as the set of resulting states from value + mask can result in a superset of the actual intended range, and as such a tnum_in(range, reg->var_off) check may yield true when it shouldn't, for example tnum_range(0, 2) would result in 00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here represented by a less precise superset of {0, 1, 2, 3}. As the register is known const scalar, really just use the concrete reg->var_off.value for the upper index check. Fixes: d2e4c1e6 ("bpf: Constant map key tracking for prog array pokes") Reported-by: NHsin-Wei Hung <hsinweih@uci.edu> Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net> Cc: Shung-Hsi Yu <shung-hsi.yu@suse.com> Acked-by: NJohn Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel@iogearbox.netSigned-off-by: NAlexei Starovoitov <ast@kernel.org> Signed-off-by: NPu Lehui <pulehui@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sishuai Gong 提交于
mainline inclusion from mainline-v5.15-rc1 commit c42dd069 category: bugfix bugzilla: 187567, https://gitee.com/openeuler/kernel/issues/I5PK1G CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/configfs/dir.c?h=v6.0-rc3&id=c42dd069be8dfc9b2239a5c89e73bbd08ab35de0 -------------------------------- When configfs_lookup() is executing list_for_each_entry(), it is possible that configfs_dir_lseek() is calling list_del(). Some unfortunate interleavings of them can cause a kernel NULL pointer dereference error Thread 1 Thread 2 //configfs_dir_lseek() //configfs_lookup() list_del(&cursor->s_sibling); list_for_each_entry(sd, ...) Fix this by grabbing configfs_dirent_lock in configfs_lookup() while iterating ->s_children. Signed-off-by: NSishuai Gong <sishuai@purdue.edu> Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.15-rc1 commit d07f132a category: bugfix bugzilla: 187567, https://gitee.com/openeuler/kernel/issues/I5PK1G CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/configfs/dir.c?h=v6.0-rc3&id=d07f132a225c013e59aa77f514ad9211ecab82ee -------------------------------- This makes it more clear what gets added to the dcache and prepares for an additional locking fix. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.15-rc1 commit 899587c8 category: bugfix bugzilla: 187567, https://gitee.com/openeuler/kernel/issues/I5PK1G CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/configfs/dir.c?h=v6.0-rc3&id=899587c8d0908e5124fd074d52bf05b4b0633a79 -------------------------------- Return the error directly instead of using a goto. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christoph Hellwig 提交于
mainline inclusion from mainline-v5.15-rc1 commit 417b962d category: bugfix bugzilla: 187567, https://gitee.com/openeuler/kernel/issues/I5PK1G CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/configfs/dir.c?h=v6.0-rc3&id=417b962ddeca2b70eb72d28c87541bdad4e234f8 -------------------------------- Just like most other file systems: get the simple checks out of the way first. Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Herbert Xu 提交于
mainline inclusion from mainline-v6.0-rc3 commit ba953a9d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5OPA4 CVE: CVE-2022-3028 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba953a9d89a00c078b85f4b190bc1dde66fe16b5 -------------------------------- When namespace support was added to xfrm/afkey, it caused the previously single-threaded call to xfrm_probe_algs to become multi-threaded. This is buggy and needs to be fixed with a mutex. Reported-by: NAbhishek Shah <abhishek.shah@columbia.edu> Fixes: 283bc9f3 ("xfrm: Namespacify xfrm state/policy locks") Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com> Signed-off-by: NXu Jia <xujia39@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 08afa87f58d83dfe040572ed591b47e8cb9e225c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=08afa87f58d83dfe040572ed591b47e8cb9e225c -------------------------------- 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> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit a4bb7ef2d6f6d7158539f95b2fa97d658ea3cf75 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a4bb7ef2d6f6d7158539f95b2fa97d658ea3cf75 -------------------------------- commit 716b1058 upstream. We will need this new helper in the next patch. Cc: Hillf Danton <hdanton@sina.com> Cc: 一只狗 <chennbnbnb@gmail.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20220707082558.9250-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit c84986d097451203bb79a8bff8d37e56488fbf1d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c84986d097451203bb79a8bff8d37e56488fbf1d -------------------------------- 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: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 4d374625cca21ce4f9cdd58170d070b400910ae2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4d374625cca21ce4f9cdd58170d070b400910ae2 -------------------------------- commit b68b9144 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). We are going to remove the latter (as it is used less), so call the former in the rest of the users. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: William Hubbs <w.d.hubbs@gmail.com> Cc: Chris Brannon <chris@the-brannons.com> Cc: Kirk Reiser <kirk@reisers.ca> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-3-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jiri Slaby 提交于
stable inclusion from stable-v5.10.134 commit 6a81848252869d929354a879e08807c932444929 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5A5Y1 CVE: CVE-2022-1462 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a81848252869d929354a879e08807c932444929 -------------------------------- commit 5f6a8515 upstream. Since commit a9c3f68f (tty: Fix low_latency BUG) in 2014, tty_flip_buffer_push() is only a wrapper to tty_schedule_flip(). We are going to remove the latter (as it is used less), so call the former in drivers/tty/. Cc: Vladimir Zapolskiy <vz@mleia.com> Reviewed-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20211122111648.30379-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYi Yang <yiyang13@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sarthak Kukreti 提交于
stable inclusion from stable-v5.10.120 commit 8df42bcd364cc3b41105215d841792aea787b133 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8df42bcd364cc3b41105215d841792aea787b133 -------------------------------- commit 4caae584 upstream. The device-mapper framework provides a mechanism to mark targets as immutable (and hence fail table reloads that try to change the target type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's feature flags to prevent switching the verity target with a different target type. Fixes: a4ffc152 ("dm: add verity target") Cc: stable@vger.kernel.org Signed-off-by: NSarthak Kukreti <sarthakkukreti@google.com> Reviewed-by: NKees Cook <keescook@chromium.org> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Conflicts: drivers/md/dm-verity-target.c Reviewed-by: NLuo Meng <luomeng12@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 David Howells 提交于
stable inclusion from stable-v5.10.120 commit 8fbd54ab06c955d247c1a91d5d980cddc868f1e7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6BR Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8fbd54ab06c955d247c1a91d5d980cddc868f1e7 -------------------------------- commit 189b0ddc upstream. pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to prevent post_one_notification() from trying to insert into the ring whilst the ring is being replaced. The occupancy check must be done after the lock is taken, and the lock must be taken after the new ring is allocated. The bug can lead to an oops looking something like: BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840 Read of size 4 at addr ffff88801cc72a70 by task poc/27196 ... Call Trace: post_one_notification.isra.0+0x62e/0x840 __post_watch_notification+0x3b7/0x650 key_create_or_update+0xb8b/0xd20 __do_sys_add_key+0x175/0x340 __x64_sys_add_key+0xbe/0x140 do_syscall_64+0x5c/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero Day Initiative. Fixes: c73be61c ("pipe: Add general notification queue support") Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291 Signed-off-by: NDavid Howells <dhowells@redhat.com> 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>
-
- 05 9月, 2022 12 次提交
-
-
由 David Hildenbrand 提交于
mainline inclusion from mainline-v5.19-rc1 commit 50053941 category: bugfix bugzilla: 187533, https://gitee.com/openeuler/kernel/issues/I5OITX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=500539419fae0aeb27189b2d62a238a056ca6742 -------------------------------- We can already theoretically fail to unmap (still having page_mapped()) in case arch_unmap_one() fails, which can happen on sparc. Failures to unmap are handled gracefully, just as if there are other references on the target page: freezing the refcount in split_huge_page_to_list() will fail if still mapped and we'll simply remap. In commit 504e070d ("mm: thp: replace DEBUG_VM BUG with VM_WARN when unmap fails for split") we already converted to VM_WARN_ON_ONCE_PAGE, let's get rid of it completely now. This is a preparation for making try_to_migrate() fail on anonymous pages with GUP pins, which will make this VM_WARN_ON_ONCE_PAGE trigger more frequently. Link: https://lkml.kernel.org/r/20220428083441.37290-11-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com> Reported-by: NYang Shi <shy828301@gmail.com> Reviewed-by: NYang Shi <shy828301@gmail.com> Acked-by: NVlastimil Babka <vbabka@suse.cz> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: David Rientjes <rientjes@google.com> Cc: Don Dutile <ddutile@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Jan Kara <jack@suse.cz> Cc: Jann Horn <jannh@google.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Khalid Aziz <khalid.aziz@oracle.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Liang Zhang <zhangliang5@huawei.com> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Nadav Amit <namit@vmware.com> Cc: Oded Gabbay <oded.gabbay@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Pedro Demarchi Gomes <pedrodemargomes@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lecopzer Chen 提交于
mainline inclusion from mainline-v6.0-rc1 commit 8fa7ea40 category: bugfix bugzilla: 187412, https://gitee.com/openeuler/kernel/issues/I5O5X9?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8fa7ea40bf56945c3ff5af00c0dca1fd9e26f129 -------------------------------- When we run out of module space address with ko insertion, and with MODULE_PLTS, module would turn to try to find memory from VMALLOC address space. Unfortunately, with KASAN enabled, VMALLOC doesn't work without KASAN_VMALLOC, thus select KASAN_VMALLOC by default. 8<--- cut here --- Unable to handle kernel paging request at virtual address bd300860 [bd300860] *pgd=41cf1811, *pte=41cf26df, *ppte=41cf265f Internal error: Oops: 80f [#1] PREEMPT SMP ARM Modules linked in: hello(O+) CPU: 0 PID: 89 Comm: insmod Tainted: G O 5.16.0-rc6+ #19 Hardware name: Generic DT based system PC is at mmioset+0x30/0xa8 LR is at 0x0 pc : [<c077ed30>] lr : [<00000000>] psr: 20000013 sp : c451fc18 ip : bd300860 fp : c451fc2c r10: f18042cc r9 : f18042d0 r8 : 00000000 r7 : 00000001 r6 : 00000003 r5 : 01312d00 r4 : f1804300 r3 : 00000000 r2 : 00262560 r1 : 00000000 r0 : bd300860 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 43e9406a DAC: 00000051 Register r0 information: non-paged memory Register r1 information: NULL pointer Register r2 information: non-paged memory Register r3 information: NULL pointer Register r4 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r5 information: non-paged memory Register r6 information: non-paged memory Register r7 information: non-paged memory Register r8 information: NULL pointer Register r9 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r10 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r11 information: non-slab/vmalloc memory Register r12 information: non-paged memory Process insmod (pid: 89, stack limit = 0xc451c000) Stack: (0xc451fc18 to 0xc4520000) fc00: f18041f0 c04803a4 fc20: c451fc44 c451fc30 c048053c c0480358 f1804030 01312cff c451fc64 c451fc48 fc40: c047f330 c0480500 f18040c0 c1b52ccc 00000001 c5be7700 c451fc74 c451fc68 fc60: f1802098 c047f300 c451fcb4 c451fc78 c026106c f180208c c4880004 00000000 fc80: c451fcb4 bf001000 c044ff48 c451fec0 f18040c0 00000000 c1b54cc4 00000000 fca0: c451fdf0 f1804268 c451fe64 c451fcb8 c0264e88 c0260d48 ffff8000 00007fff fcc0: f18040c0 c025cd00 c451fd14 00000003 0157f008 f1804258 f180425c f1804174 fce0: f1804154 f180424c f18041f0 f180414c f1804178 f18041c0 bf0025d4 188a3fa8 fd00: 0000009e f1804170 f2b18000 c451ff10 c0d92e40 f180416c c451feec 00000001 fd20: 00000000 c451fec8 c451fe20 c451fed0 f18040cc 00000000 f17ea000 c451fdc0 fd40: 41b58ab3 c1387729 c0261c28 c047fb5c c451fe2c c451fd60 c0525308 c048033c fd60: 188a3fb4 c3ccb090 c451fe00 c3ccb080 00000000 00000000 00016920 00000000 fd80: c02d0388 c047f55c c02d0388 00000000 c451fddc c451fda0 c02d0388 00000000 fda0: 41b58ab3 c13a72d0 c0524ff0 c1705f48 c451fdfc c451fdc0 c02d0388 c047f55c fdc0: 00016920 00000000 00000003 c1bb2384 c451fdfc c3ccb080 c1bb2384 00000000 fde0: 00000000 00000000 00000000 00000000 c451fe1c c451fe00 c04e9d70 c1705f48 fe00: c1b54cc4 c1bbc71c c3ccb080 00000000 c3ccb080 00000000 00000003 c451fec0 fe20: c451fe64 c451fe30 c0525918 c0524ffc c451feb0 c1705f48 00000000 c1b54cc4 fe40: b78a3fd0 c451ff60 00000000 0157f008 00000003 c451fec0 c451ffa4 c451fe68 fe60: c0265480 c0261c34 c451feb0 7fffffff 00000000 00000002 00000000 c4880000 fe80: 41b58ab3 c138777b c02652cc c04803ec 000a0000 c451ff00 ffffff9c b6ac9f60 fea0: c451fed4 c1705f48 c04a4a90 b78a3fdc f17ea000 ffffff9c b6ac9f60 c0100244 fec0: f17ea21a f17ea300 f17ea000 00016920 f1800240 f18000ac f17fb7dc 01316000 fee0: 013161b0 00002590 01316250 00000000 00000000 00000000 00002580 00000029 ff00: 0000002a 00000013 00000000 0000000c 00000000 00000000 0157f004 c451ffb0 ff20: c1719be0 aed6f410 c451ff74 c451ff38 c0c4103c c0c407d0 c451ff84 c451ff48 ff40: 00000805 c02c8658 c1604230 c1719c30 00000805 0157f004 00000005 c451ffb0 ff60: c1719be0 aed6f410 c451ffac c451ff78 c0122130 c1705f48 c451ffac 0157f008 ff80: 00000006 0000005f 0000017b c0100244 c4880000 0000017b 00000000 c451ffa8 ffa0: c0100060 c02652d8 0157f008 00000006 00000003 0157f008 00000000 b6ac9f60 ffc0: 0157f008 00000006 0000005f 0000017b 00000000 00000000 aed85f74 00000000 ffe0: b6ac9cd8 b6ac9cc8 00030200 aecf2d60 a0000010 00000003 00000000 00000000 Backtrace: [<c048034c>] (kasan_poison) from [<c048053c>] (kasan_unpoison+0x48/0x5c) [<c04804f4>] (kasan_unpoison) from [<c047f330>] (__asan_register_globals+0x3c/0x64) r5:01312cff r4:f1804030 [<c047f2f4>] (__asan_register_globals) from [<f1802098>] (_sub_I_65535_1+0x18/0xf80 [hello]) r7:c5be7700 r6:00000001 r5:c1b52ccc r4:f18040c0 [<f1802080>] (_sub_I_65535_1 [hello]) from [<c026106c>] (do_init_module+0x330/0x72c) [<c0260d3c>] (do_init_module) from [<c0264e88>] (load_module+0x3260/0x32a8) r10:f1804268 r9:c451fdf0 r8:00000000 r7:c1b54cc4 r6:00000000 r5:f18040c0 r4:c451fec0 [<c0261c28>] (load_module) from [<c0265480>] (sys_finit_module+0x1b4/0x1e8) r10:c451fec0 r9:00000003 r8:0157f008 r7:00000000 r6:c451ff60 r5:b78a3fd0 r4:c1b54cc4 [<c02652cc>] (sys_finit_module) from [<c0100060>] (ret_fast_syscall+0x0/0x1c) Exception stack(0xc451ffa8 to 0xc451fff0) ffa0: 0157f008 00000006 00000003 0157f008 00000000 b6ac9f60 ffc0: 0157f008 00000006 0000005f 0000017b 00000000 00000000 aed85f74 00000000 ffe0: b6ac9cd8 b6ac9cc8 00030200 aecf2d60 r10:0000017b r9:c4880000 r8:c0100244 r7:0000017b r6:0000005f r5:00000006 r4:0157f008 Code: e92d4100 e1a08001 e1a0e003 e2522040 (a8ac410a) ---[ end trace df6e12843197b6f5 ]--- Signed-off-by: NLecopzer Chen <lecopzer.chen@mediatek.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: NXia Longlong <xialonglong1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lecopzer Chen 提交于
mainline inclusion from mainline-v6.0-rc1 commit 565cbaad category: bugfix bugzilla: 187411, https://gitee.com/openeuler/kernel/issues/I5O600?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=565cbaad83d83e288927b96565211109bc984007 -------------------------------- Simply make shadow of vmalloc area mapped on demand. Since the virtual address of vmalloc for Arm is also between MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow address has already included between KASAN_SHADOW_START and KASAN_SHADOW_END. Thus we need to change nothing for memory map of Arm. This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem and support CONFIG_VMAP_STACK with KASan. Signed-off-by: NLecopzer Chen <lecopzer.chen@mediatek.com> Tested-by: NLinus Walleij <linus.walleij@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: NXia Longlong <xialonglong1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lecopzer Chen 提交于
mainline inclusion from mainline-v5.13-rc1 commit acc3042d category: bugfix bugzilla: 187409, https://gitee.com/openeuler/kernel/issues/I5O5YA?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=acc3042d62cb92c3776767f09f665511c903ef2d -------------------------------- Before this patch, someone who wants to use VMAP_STACK when KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC. >From Will's suggestion [1]: > I would _really_ like to move to VMAP stack unconditionally, and > that would effectively force KASAN_VMALLOC to be set if KASAN is in use Because VMAP_STACK now depends on either HW_TAGS or KASAN_VMALLOC if KASAN enabled, in order to make VMAP_STACK selected unconditionally, we bind KANSAN_GENERIC and KASAN_VMALLOC together. Note that SW_TAGS supports neither VMAP_STACK nor KASAN_VMALLOC now, so this is the first step to make VMAP_STACK selected unconditionally. Bind KANSAN_GENERIC and KASAN_VMALLOC together is supposed to cost more memory at runtime, thus the alternative is using SW_TAGS KASAN instead. [1]: https://lore.kernel.org/lkml/20210204150100.GE20815@willie-the-truck/Suggested-by: NWill Deacon <will@kernel.org> Signed-off-by: NLecopzer Chen <lecopzer.chen@mediatek.com> Link: https://lore.kernel.org/r/20210324040522.15548-6-lecopzer.chen@mediatek.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NXia Longlong <xialonglong1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Eric Dumazet 提交于
stable inclusion from stable-v5.10.137 commit d0412d8f693e6f00b6cda80cc3ae1fbc7c14d392 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5NYY0?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d0412d8f693e6f00b6cda80cc3ae1fbc7c14d392 -------------------------------- [ Upstream commit 7c80b038 ] If sk->sk_forward_alloc is 150000, and we need to schedule 150001 bytes, we want to allocate 1 byte more (rounded up to one page), instead of 150001 :/ Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by: NEric Dumazet <edumazet@google.com> Reviewed-by: NShakeel Butt <shakeelb@google.com> Acked-by: NSoheil Hassas Yeganeh <soheil@google.com> Signed-off-by: NJakub Kicinski <kuba@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Oliver Upton 提交于
mainline inclusion from mainline-v5.14 commit 6caa5812 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZJT CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6caa5812e2d126a0aa8a17816c1ba6f0a0c2b309 -------------------------------- Clean up handling of checks for pending work by switching to the generic infrastructure to do so. We pick up handling for TIF_NOTIFY_RESUME from this switch, meaning that task work will be correctly handled. Signed-off-by: NOliver Upton <oupton@google.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210802192809.1851010-4-oupton@google.comSigned-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Oliver Upton 提交于
mainline inclusion from mainline-v5.14 commit e1c6b9e1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZJT CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1c6b9e1669e44fb7f9688e34e460b759e3b9187 -------------------------------- Some architectures (e.g. arm64) have yet to adopt the generic entry infrastructure. Despite that, it would be nice to use some common plumbing for guest entry/exit handling. For example, KVM/arm64 currently does not handle TIF_NOTIFY_PENDING correctly. Allow use of only the generic KVM entry code by tightening up the include list. No functional change intended. Signed-off-by: NOliver Upton <oupton@google.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210802192809.1851010-3-oupton@google.comSigned-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Oliver Upton 提交于
mainline inclusion from mainline-v5.14 commit fe5161d2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4VZJT CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe5161d2c39b8c2801f0e786631460c6e8a1cae4 -------------------------------- Most other architectures that implement KVM record a statistic indicating the number of times a vCPU has exited due to a pending signal. Add support for that stat to arm64. Reviewed-by: NJing Zhang <jingzhangos@google.com> Signed-off-by: NOliver Upton <oupton@google.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210802192809.1851010-2-oupton@google.comSigned-off-by: NZhang Qiao <zhangqiao22@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luo Meng 提交于
mainline inclusion from mainline-v5.19 commit 3534e5a5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5GRX6 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 -------------------------------- Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold". Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed") Cc: stable@vger.kernel.org Reported-by: NHulk Robot <hulkci@huawei.com> Signed-off-by: NLuo Meng <luomeng12@huawei.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Luo Meng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5KK4D CVE: NA -------------------------------- This reverts commit f4f11702. 7f3945b4aab5 (NFS: Use of mapping_set_error() results in spurious errors) delete mappint->flags because of 67dd23f9 (nfs: ensure correct writeback errors are returned on close()). However 67dd23f9 has been reverted, use mappint->flags to return error. Signed-off-by: NLuo Meng <luomeng12@huawei.com> Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhengzengkai Memory reliable feature is a memory tiering mechanism. It is based on kernel mirror feature, which splits memory into two sperate regions, mirrored(reliable) region and non-mirrored (non-reliable) region. for kernel mirror feature: allocate kernel memory from mirrored region by default allocate user memory from non-mirrored region by default non-mirrored region will be arranged into ZONE_MOVABLE. for kernel reliable feature, it has additional features below: normal user tasks never alloc memory from mirrored region with userspace apis(malloc, mmap, etc.) special user tasks will allocate memory from mirrored region by default tmpfs/pagecache allocate memory from mirrored region by default upper limit of mirrored region allcated for user tasks, tmpfs and pagecache Support Reliable fallback mechanism which allows special user tasks, tmpfs and pagecache can fallback to alloc non-mirrored region, it's the default setting. In order to fulfil the goal ___GFP_RELIABILITY flag added for alloc memory from mirrored region. the high_zoneidx for special user tasks/tmpfs/pagecache is set to ZONE_NORMAL. normal user tasks could only alloc from ZONE_MOVABLE. This patch is just the main framework, memory reliable support for special user tasks, pagecache and tmpfs has own patches. To enable this function, mirrored(reliable) memory is needed and "kernelcore=reliable" should be added to kernel parameters. Link:https://gitee.com/openeuler/kernel/pulls/79 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> -
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhengzengkai With the increase of memory capacity and density, the probability of memory error increases. The increasing size and density of server RAM in the data center and cloud have shown increased uncorrectable memory errors. Currently, the kernel has a mechanism to recover from hardware memory errors. This patchset provides an new recovery mechanism. For arm64, the hardware memory error handling is do_sea() which divided into two cases: 1. The user state consumed the memory errors, the solution is kill the user process and isolate the error page. 2. The kernel state consumed the memory errors, the solution is panic. For case 2, Undifferentiated panic maybe not the optimal choice, it can be handled better, in some scenarios, we can avoid panic, such as uaccess, if the uaccess fails due to memory error, only the user process will be affected, kill the user process and isolate the user page with hardware memory errors is a better choice. Link:https://gitee.com/openeuler/kernel/pulls/78 Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 02 9月, 2022 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhengzengkai BMC is an in-kernel key-value cache implemented in BPF and proposed by paper [1]. The paper discussed BMC for memcached, obtaining at least 6x performance speedup. This patch implements a sample BMC for Redis. Paper [1] implements BMC in XDP, bypassing the kernel network stack totally. Since Redis is based on TCP protocol, and it's almost impossible to fully process TCP traffic in XDP, so this patch implements BMC in sockmap, which locates at the top of kernel network stack. Since kernel network stack is not bypassed, the speedup is not significant. Any way, this is only a sample implementation, and performance improvements can be continuously optimized. See [2] for details on how to build samples/bpf. Output files: samples/bpf/bmctool samples/bpf/bmc/bpf.o Sample usage: bmctool prog load -p 6379 ./bmc/bpf.o # load bmc bpf prog and attach it # to sockets with listen port 6379 bmctool stat # dump bmc status bmctool prog unload # detach and unload bmc prog [1] https://www.usenix.org/conference/nsdi21/presentation/ghigoff [2] https://www.kernel.org/doc/readme/samples-bpf-README.rst Link:https://gitee.com/openeuler/kernel/pulls/69 Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 01 9月, 2022 1 次提交
-
-
由 Wei Huang 提交于
mainline inclusion from mainline-5.15 commit cb0f722a category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU CVE: NA ------------------------------------------------- When the 5-level page table CPU flag is set in the host, but the guest has CR4.LA57=0 (including the case of a 32-bit guest), the top level of the shadow NPT page tables will be fixed, consisting of one pointer to a lower-level table and 511 non-present entries. Extend the existing code that creates the fixed PML4 or PDP table, to provide a fixed PML5 table if needed. This is not needed on EPT because the number of layers in the tables is specified in the EPTP instead of depending on the host CR4. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NWei Huang <wei.huang2@amd.com> Message-Id: <20210818165549.3771014-3-wei.huang2@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-
- 31 8月, 2022 3 次提交
-
-
由 Suravee Suthikulpanit 提交于
mainline inclusion from mainline-5.18-rc1 commit 4a204f78 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU CVE: NA ------------------------------------------------- Expand KVM's mask for the AVIC host physical ID to the full 12 bits defined by the architecture. The number of bits consumed by hardware is model specific, e.g. early CPUs ignored bits 11:8, but there is no way for KVM to enumerate the "true" size. So, KVM must allow using all bits, else it risks rejecting completely legal x2APIC IDs on newer CPUs. This means KVM relies on hardware to not assign x2APIC IDs that exceed the "true" width of the field, but presumably hardware is smart enough to tie the width to the max x2APIC ID. KVM also relies on hardware to support at least 8 bits, as the legacy xAPIC ID is writable by software. But, those assumptions are unavoidable due to the lack of any way to enumerate the "true" width. Cc: stable@vger.kernel.org Cc: Maxim Levitsky <mlevitsk@redhat.com> Suggested-by: NSean Christopherson <seanjc@google.com> Reviewed-by: NSean Christopherson <seanjc@google.com> Fixes: 44a95dae ("KVM: x86: Detect and Initialize AVIC support") Signed-off-by: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com> Message-Id: <20220211000851.185799-1-suravee.suthikulpanit@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-
由 Maxim Levitsky 提交于
mainline inclusion from mainline-v5.17 commit 39150352 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU CVE: NA ------------------------------------------------- asm/svm.h is the correct place for all values that are defined in the SVM spec, and that includes AVIC. Also add some values from the spec that were not defined before and will be soon useful. Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20220207155447.840194-10-mlevitsk@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-
由 Wei Huang 提交于
mainline inclusion from mainline-v5.15 commit 43e540cc category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU CVE: NA ------------------------------------------------- When the 5-level page table is enabled on host OS, the nested page table for guest VMs must use 5-level as well. Update get_npt_level() function to reflect this requirement. In the meanwhile, remove the code that prevents kvm-amd driver from being loaded when 5-level page table is detected. Signed-off-by: NWei Huang <wei.huang2@amd.com> Message-Id: <20210818165549.3771014-4-wei.huang2@amd.com> [Tweak condition as suggested by Sean. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-