- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] tracing: Reject incomplete event filter expressions
by Pu Lehui 03 Nov '26

03 Nov '26

From: Kyle Zeng <kylebot(a)openai.com> stable inclusion from stable-v5.10.273 commit 4a1a6d35359991c5d47f4bf101cfbe1475c94093 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/21084 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 1fdc4164e488916402badddbb1f51e9380dabb91 upstream. A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations. Fixes: 80765597bc587 ("tracing: Rewrite filter logic to be simpler and faster") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20261023174620.91969-1-kylebot@openai.com Assisted-by: Codex:gpt-6-astra Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Tested-by: JongHyuk Kim(MalHyuk) <malhyuk97(a)gmail.com> Signed-off-by: Kyle Zeng <kylebot(a)openai.com> Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Co-authored-by: BackportAgent(a)deepseek-v4.1-flash Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/trace/trace_events_filter.c | 6 +++++ .../test.d/filter/event-filter-incomplete.tc | 24 +++++++++++++++++++ 2 files changed, 30 insertions(+) create mode 100644 tools/testing/selftests/ftrace/test.d/filter/event-filter-incomplete.tc diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c index 8c38db5ed18f..a8c40238b1ba 100644 --- a/kernel/trace/trace_events_filter.c +++ b/kernel/trace/trace_events_filter.c @@ -537,6 +537,12 @@ predicate_parse(const char *str, int nr_parens, int nr_preds, top--; /* #12 */ } } + /* Only the inner loop can complete a non-empty expression. */ + if (N) { + ret = -EINVAL; + parse_error(pe, FILT_ERR_INVALID_FILTER, ptr - str); + goto out_free; + } out: if (top != op_stack) { /* Too many '(' */ diff --git a/tools/testing/selftests/ftrace/test.d/filter/event-filter-incomplete.tc b/tools/testing/selftests/ftrace/test.d/filter/event-filter-incomplete.tc new file mode 100644 index 000000000000..cc6df762845f --- /dev/null +++ b/tools/testing/selftests/ftrace/test.d/filter/event-filter-incomplete.tc @@ -0,0 +1,24 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0 +# description: event filter - reject incomplete logical expressions +# requires: events/sched/sched_switch/filter +# flags: instance + +filter=events/sched/sched_switch/filter + +for base in \ + 'common_pid == 1' \ + 'common_pid == 1 || common_pid == 2' \ + 'common_pid == 1 && common_pid == 2' \ + '!(common_pid == 1 || common_pid == 2)' +do + printf '%s' "$base" > "$filter" + for tail in '&&' '||' '&& !' '|| !' '&& !! ' '|| !! '; do + if printf '%s' "$base $tail" > "$filter" 2>/dev/null; then + echo "Accepted incomplete filter: $base $tail" + exit_fail + fi + done +done + +echo 0 > "$filter" -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Propagate btf_add_type() errors in btf_check_all_metas()
by Pu Lehui 03 Nov '26

03 Nov '26

From: Feng Yang <yangfeng(a)kylinos.cn> mainline inclusion from mainline-v7.4-rc1 commit fb2b27d214c3b88d926a303267dd83cfdb428b13 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10194 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- btf_check_all_metas() ignores the return value of btf_add_type(), so a type that could not be registered is silently dropped while the loop keeps walking over the type section. Both failure modes are reachable: - -E2BIG. Once the types array reaches its capacity (BTF_MAX_TYPE), every following btf_add_type() fails the same way, so btf_check_all_metas() still returns 0 and the BTF object is created with btf->nr_types capped while hdr->type_len claims more records. - -ENOMEM. btf->nr_types is not incremented and the array is not grown, so the next type is recorded at the slot of the dropped one and btf->types[] stays off by one with respect to the type ids for all remaining types. btf_type_by_id() then returns the wrong type for those ids for the whole lifetime of the object, and the last type is silently left unresolved. Propagate the error so that the object is rejected instead. Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)") Signed-off-by: Feng Yang <yangfeng(a)kylinos.cn> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Reviewed-by: Mahe Tardy <mahe.tardy(a)gmail.com> Acked-by: Alan Maguire <almagui(a)kernel.org> Link: https://patch.msgid.link/20261022064727.747304-1-yangfeng59949@163.com Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/btf.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 558ef5930a7d..66ee3dc4d040 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -5063,6 +5063,7 @@ static int btf_check_all_metas(struct btf_verifier_env *env) struct btf *btf = env->btf; struct btf_header *hdr; void *cur, *end; + int err; hdr = &btf->hdr; cur = btf->nohdr_data + hdr->type_off; @@ -5077,7 +5078,10 @@ static int btf_check_all_metas(struct btf_verifier_env *env) if (meta_size < 0) return meta_size; - btf_add_type(env, t); + err = btf_add_type(env, t); + if (err) + return err; + cur += meta_size; env->log_type_id++; } -- 2.34.1

2 1

[PATCH OLK-5.10] vfio/pci: clear vdev->msi_perm after freeing it on init failure
by Zhang Yuwei 03 Nov '26

03 Nov '26

From: Xiang Mei <xmei5(a)asu.edu> stable inclusion from stable-v5.10.270 commit eb84cd81040e58dd05ac190f561f2115e3367249 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10236 CVE: CVE-2026-89777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi <bestswngs(a)gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson <alex(a)shazbot.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/vfio/pci/vfio_pci_config.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c index 7a4b7b8b432c..a23e4975694f 100644 --- a/drivers/vfio/pci/vfio_pci_config.c +++ b/drivers/vfio/pci/vfio_pci_config.c @@ -1221,6 +1221,7 @@ static int vfio_msi_cap_len(struct vfio_pci_device *vdev, u8 pos) ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); + vdev->msi_perm = NULL; return ret; } -- 2.22.0

2 1

[PATCH OLK-5.10] vfio/pci: clear vdev->msi_perm after freeing it on init failure
by Zhang Yuwei 03 Nov '26

03 Nov '26

From: Xiang Mei <xmei5(a)asu.edu> stable inclusion from stable-v5.10.270 commit eb84cd81040e58dd05ac190f561f2115e3367249 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/10236 CVE: CVE-2026-89777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi <bestswngs(a)gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson <alex(a)shazbot.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/vfio/pci/vfio_pci_config.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c index 7a4b7b8b432c..a23e4975694f 100644 --- a/drivers/vfio/pci/vfio_pci_config.c +++ b/drivers/vfio/pci/vfio_pci_config.c @@ -1221,6 +1221,7 @@ static int vfio_msi_cap_len(struct vfio_pci_device *vdev, u8 pos) ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); + vdev->msi_perm = NULL; return ret; } -- 2.22.0

2 1

[PATCH OLK-6.6] nvdimm: pmem: keep PREFLUSH before data writes
by Yi Yang 03 Nov '26

03 Nov '26

From: Li Chen <me(a)linux.beauty> stable inclusion from stable-v6.6.160 commit 22d1f4dcdc9c6d0295c6db0c8933126098b14e05 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19893 CVE: CVE-2026-98161 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c644a2f8fef5618fcf453c591177700fd07dd024 ] pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier. Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio. Signed-off-by: Li Chen <me(a)linux.beauty> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Message-ID: <20260630092338.2094628-3-me(a)linux.beauty> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/nvdimm/pmem.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 9fe358090720..7445114b5637 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -209,8 +209,14 @@ static void pmem_submit_bio(struct bio *bio) struct pmem_device *pmem = bio->bi_bdev->bd_disk->private_data; struct nd_region *nd_region = to_region(pmem); - if (bio->bi_opf & REQ_PREFLUSH) - ret = nvdimm_flush(nd_region, bio); + if (bio->bi_opf & REQ_PREFLUSH) { + ret = nvdimm_flush(nd_region, NULL); + if (ret) { + bio->bi_status = errno_to_blk_status(ret); + bio_endio(bio); + return; + } + } do_acct = blk_queue_io_stat(bio->bi_bdev->bd_disk->queue); if (do_acct) @@ -230,7 +236,7 @@ static void pmem_submit_bio(struct bio *bio) if (do_acct) bio_end_io_acct(bio, start); - if (bio->bi_opf & REQ_FUA) + if ((bio->bi_opf & REQ_FUA) && !bio->bi_status) ret = nvdimm_flush(nd_region, bio); if (ret) -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] *** CVE-2026-98343 ***
by Hongtao Zhang 03 Nov '26

03 Nov '26

*** BLURB HERE *** Shivank Garg (2): dmaengine: Fix device kref underflow in dma_chan_put() dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel() drivers/dma/dmaengine.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6 v4 00/18] MOC bypass cache
by Jiacheng Yu 03 Nov '26

03 Nov '26

The MOC (MemoryOnChip) bypass cache feature uses the Arm Page Based Hardware Attributes (PBHA, FEAT_HPDS2) to describe per-mapping performance hints. MOC memory is not cached in the system cache, so the OS has to be told which pages may be mapped with the MOC attribute. This series adds: - stage1 PBHA support, discovered from the device tree or from the EFI stub - KVM stage2 support, including the VTCR_EL2.PBHA override mask - page based control: PROT_PBHA_BIT0, VM_PBHA_BIT0, prctl and /proc/<pid>/pbha_bit0 - the pbha= boot parameter and the MOC mode plumbing in the EFI stub Based on OLK-6.6. Changes in v4: - restore %ld when printing the static key state; %d broke the aarch64 build with -Werror=format Changes in v3: - dt-bindings: update the six stale references to arm/cpu.yaml, add the maintainers entry and fix the description - fix the for-loop style in the PBHA parsing code - move pbha.rst to Documentation/arch/arm64/ - use a free vm_flags bit for VM_PBHA_BIT0 and document the p0 mnemonic - drop the set_huge_pte_at() find_vma() lookup; the hint is carried by vm_page_prot - rewrite a live THP pmd through pmdp_invalidate_ad() - take an mm reference in pbha_bit0_read() - add a .hugetlb_entry callback so /proc/<pid>/pbha_bit0 and prctl update hugetlb mappings as well - limit the global-init flagging to current->mm - base the "nothing to do" decision on the actual VMA state instead of mm->def_flags - reject a NULL or unrecognized pbha= value Fanhua Li (2): arm64: mm: Set PBHA0 bit for VM_PBHA_BIT0 arm64: mm: Introduce procfs interface to update PBHA0 bit James Morse (7): KVM: arm64: Detect and enable PBHA for stage2 dt-bindings: Rename the description of cpu nodes cpu.yaml dt-bindings: arm: Add binding for Page Based Hardware Attributes arm64: cpufeature: Enable PBHA bits for stage1 arm64: mm: Add pgprot_pbha() to allow drivers to request PBHA values KVM: arm64: Configure PBHA bits for stage2 Documentation: arm64: Describe the support and expectations for PBHA Ma Wupeng (9): arm64: cpufeature: Enable PBHA for stage1 early via FDT arm64: mm: Detect and enable PBHA bit0 at early startup arm64: mm: Update kernel pte entries if pbha bit0 enabled arm64: mm: Show PBHA bit 59 as PBHA0 in ptdump arm64: mm: Introduce VM_PBHA_BIT0 to enable pbha bit0 for single vma arm64: mm: Set flag VM_PBHA_BIT0 for global init task arm64: mm: Introduce prctl to control pbha behavior arm64: mm: Introduce kernel param pbha openeuler: configs: arm64: Enable PBHA by default .../admin-guide/kernel-parameters.txt | 7 + Documentation/admin-guide/mm/pagemap.rst | 4 +- Documentation/arch/arm64/index.rst | 1 + Documentation/arch/arm64/pbha.rst | 87 +++ .../devicetree/bindings/arm/cpu.yaml | 578 ++++++++++++++++ .../devicetree/bindings/arm/cpus.yaml | 622 ++---------------- .../devicetree/bindings/cpu/cpu-capacity.txt | 2 +- .../devicetree/bindings/cpu/cpu-topology.txt | 2 +- .../devicetree/bindings/cpu/idle-states.yaml | 2 +- .../interrupt-controller/apple,aic.yaml | 2 +- .../interrupt-controller/apple,aic2.yaml | 2 +- .../interrupt-controller/arm,gic-v3.yaml | 2 +- Documentation/filesystems/proc.rst | 1 + arch/arm64/Kconfig | 19 + arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/cpufeature.h | 15 + arch/arm64/include/asm/kvm_arm.h | 1 + arch/arm64/include/asm/kvm_pgtable.h | 9 + arch/arm64/include/asm/mman.h | 7 + arch/arm64/include/asm/pgtable-hwdef.h | 6 + arch/arm64/include/asm/pgtable.h | 26 + arch/arm64/include/asm/setup.h | 1 + arch/arm64/include/uapi/asm/mman.h | 1 + arch/arm64/kernel/cpufeature.c | 258 ++++++++ arch/arm64/kernel/head.S | 3 + arch/arm64/kernel/image-vars.h | 2 + arch/arm64/kvm/hyp/pgtable.c | 16 +- arch/arm64/mm/fixmap.c | 2 + arch/arm64/mm/mmap.c | 3 + arch/arm64/mm/mmu.c | 13 +- arch/arm64/mm/ptdump.c | 5 + arch/arm64/tools/cpucaps | 6 +- .../firmware/efi/libstub/efi-stub-helper.c | 3 + drivers/firmware/efi/libstub/fdt.c | 52 ++ drivers/soc/hisilicon/Makefile | 1 + drivers/soc/hisilicon/pbha.c | 265 ++++++++ fs/proc/base.c | 124 ++++ fs/proc/task_mmu.c | 18 + include/linux/mm.h | 8 +- include/linux/pbha.h | 93 +++ include/uapi/asm-generic/mman-common.h | 1 + include/uapi/linux/prctl.h | 1 + kernel/sys.c | 10 + mm/memory.c | 4 + mm/vmalloc.c | 4 + tools/include/uapi/asm-generic/mman-common.h | 1 + 46 files changed, 1725 insertions(+), 566 deletions(-) create mode 100644 Documentation/arch/arm64/pbha.rst create mode 100644 Documentation/devicetree/bindings/arm/cpu.yaml create mode 100644 drivers/soc/hisilicon/pbha.c create mode 100644 include/linux/pbha.h

2 19

[PATCH OLK-6.6 0/2] Fix CVE-2026-97480 for OLK-6.6
by Yi Yang 03 Nov '26

03 Nov '26

*** BLURB HERE *** Jiri Slaby (SUSE) (1): serial: 8250: invert serial8250_register_8250_port() CIR condition Stepan Ionichev (1): tty: serial: 8250: protect against NULL uart->port.dev in register drivers/tty/serial/8250/8250_core.c | 253 ++++++++++++++-------------- 1 file changed, 127 insertions(+), 126 deletions(-) -- 2.25.1

2 3

[PATCH OLK-5.10] vfio/pci: clear vdev->msi_perm after freeing it on init failure
by Zhang Yuwei 03 Nov '26

03 Nov '26

From: Xiang Mei <xmei5(a)asu.edu> stable inclusion from stable-v5.10.270 commit eb84cd81040e58dd05ac190f561f2115e3367249 category: bugfix bugzilla: https://gitcode.com/src-openeuler/kernel/issues/21108 CVE: CVE-2026-89777 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi <bestswngs(a)gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson <alex(a)shazbot.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/vfio/pci/vfio_pci_config.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c index 7a4b7b8b432c..a23e4975694f 100644 --- a/drivers/vfio/pci/vfio_pci_config.c +++ b/drivers/vfio/pci/vfio_pci_config.c @@ -1221,6 +1221,7 @@ static int vfio_msi_cap_len(struct vfio_pci_device *vdev, u8 pos) ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); + vdev->msi_perm = NULL; return ret; } -- 2.22.0

2 1

[PATCH OLK-5.10] vfio/pci: clear vdev->msi_perm after freeing it on init failure
by Zhang Yuwei 03 Nov '26

03 Nov '26

From: Xiang Mei <xmei5(a)asu.edu> stable inclusion from stable-v5.10.270 commit eb84cd81040e58dd05ac190f561f2115e3367249 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc77acfeb979dded39b247b60fef0399536bfa77 ] vfio_msi_cap_len() lazily allocates the per-device MSI permission table: vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT); if (!vdev->msi_perm) return -ENOMEM; ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); return ret; /* vdev->msi_perm left dangling */ } When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the error path frees vdev->msi_perm but leaves the freed pointer stored in it. vdev->msi_perm is not re-zeroed later because struct vfio_pci_core_device is per-device and persists across open/close cycles, and the vfio_config_init() error path returns without calling vfio_config_free(). So the dangling pointer outlives the failed open. That leads to two use-after-frees on the same device: 1. Reuse. The next vfio_config_init() sees the stale pointer at "if (vdev->msi_perm) return len;" and reuses the freed object. MSI config accesses in vfio_pci_config_rw_single() then dereference and call the freed perm->readfn / perm->writefn function pointers. 2. Double free. A later vfio_config_free() runs free_perm_bits() and kfree() on the already-freed object. Fix it by NULLing vdev->msi_perm after the kfree(), matching the NULL-after-free discipline already used in free_perm_bits() and vfio_config_free(). BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) Read of size 8 at addr ffff88800fcc88d0 by task exploit/143 Call Trace: ... kasan_report (mm/kasan/report.c:595) vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961) vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986) vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599) vfs_read (fs/read_write.c:572) __x64_sys_pread64 (fs/read_write.c:764) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Followed on device close by a double free of the same object: Oops: general protection fault, probably for non-canonical address 0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI RIP: 0010:kfree (mm/slub.c:6711) Call Trace: vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861) vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685) vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777) vfio_df_close (drivers/vfio/vfio_main.c:602) vfio_device_fops_release (drivers/vfio/vfio_main.c:648) __fput (fs/file_table.c:512) __x64_sys_close (fs/open.c:1496) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Kernel panic - not syncing: Fatal exception Fixes: 30ea32ab1951 ("vfio/pci: Fix potential memory leak in vfio_msi_cap_len") Reported-by: Weiming Shi <bestswngs(a)gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5(a)asu.edu> Link: https://lore.kernel.org/r/20260705014010.1297885-1-xmei5@asu.edu Signed-off-by: Alex Williamson <alex(a)shazbot.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> --- drivers/vfio/pci/vfio_pci_config.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c index 7a4b7b8b432c..a23e4975694f 100644 --- a/drivers/vfio/pci/vfio_pci_config.c +++ b/drivers/vfio/pci/vfio_pci_config.c @@ -1221,6 +1221,7 @@ static int vfio_msi_cap_len(struct vfio_pci_device *vdev, u8 pos) ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags); if (ret) { kfree(vdev->msi_perm); + vdev->msi_perm = NULL; return ret; } -- 2.22.0

2 1