- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save
by Zhang Kunbo 29 Sep '26

29 Sep '26

From: Fuad Tabba <fuad.tabba(a)linux.dev> mainline inclusion from mainline-v7.3-rc1 commit c6c156d931c33b92362383cf76f6d6e1291dcbfe category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19092 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths. Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have. Fixes: eff484e0298da ("KVM: arm64: vgic-its: ITT save and restore") Cc: stable(a)vger.kernel.org Signed-off-by: Fuad Tabba <fuad.tabba(a)linux.dev> Link: https://patch.msgid.link/20260807104102.2410744-2-fuad.tabba@linux.dev Signed-off-by: Oliver Upton <oupton(a)kernel.org> Conflicts: arch/arm64/kvm/vgic/vgic-its.c [ 3b2c81d5feb2 ("KVM: arm64: vgic-its: Add stronger type-checking to the ITS entry sizes") not merged] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/arm64/kvm/vgic/vgic-its.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c index acf611bc6f7e..c76591f17a1c 100644 --- a/arch/arm64/kvm/vgic/vgic-its.c +++ b/arch/arm64/kvm/vgic/vgic-its.c @@ -2234,6 +2234,14 @@ static int vgic_its_save_ite(struct vgic_its *its, struct its_device *dev, u32 next_offset; u64 val; + /* + * MAPC with V=0 keeps the ITEs mapped but drops their collection, + * and with it the ICID. Save a zeroed entry, which the restore path + * reads back as invalid. + */ + if (!ite->collection) + return vgic_its_write_entry_lock(its, gpa, 0ULL, ite_esz); + next_offset = compute_next_eventid_offset(&dev->itt_head, ite); val = ((u64)next_offset << KVM_ITS_ITE_NEXT_SHIFT) | ((u64)ite->irq->intid << KVM_ITS_ITE_PINTID_SHIFT) | -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] nfsd: fix XDR length calculation in nfsd4_ff_encode_layoutget
by Cai Xinchen 29 Sep '26

29 Sep '26

From: Jeff Layton <jlayton(a)kernel.org> stable inclusion from stable-v5.10.270 commit 3a7fd224df0fbb42167eb1b77be45d72fe0b1098 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18937 CVE: CVE-2026-89674 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f9868174af49d207fbaf0c5e055d088a983684af upstream. The XDR buffer size calculation in nfsd4_ff_encode_layoutget() has multiple errors that can result in either an out-of-bounds write or leaking uninitialized kernel memory to the client: - fh_len doesn't account for XDR padding on the file handle data - uid and gid lengths use "8 + len" but xdr_encode_opaque() actually writes "4 + xdr_align_size(len)" bytes - ds_len omits the flags and stats_collect_hint fields (8 bytes), while len's header constant overestimates by 8 bytes -- these partially cancel but leave a net mismatch The worst case occurs with short strings (e.g. uid=0, gid=0 with an odd-sized file handle), where the function writes up to 5 bytes past the reserved XDR buffer. Conversely, when string lengths happen to be 4-byte aligned, the reservation is too large and stale buffer content is sent to the client. Fix this by breaking out every encoded field explicitly in the ds_len calculation, using xdr_align_size() for all variable-length opaque fields, and correcting the header constants. Fixes: 9b9960a0ca47 ("nfsd: Add a super simple flex file server") Cc: stable(a)vger.kernel.org Assisted-by: kres:claude-opus-4-7 Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://patch.msgid.link/20260528-pnfs-fixes-v1-1-8a1255ae2f16@kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- fs/nfsd/flexfilelayoutxdr.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/fs/nfsd/flexfilelayoutxdr.c b/fs/nfsd/flexfilelayoutxdr.c index e81d2a5cf381..f9aaf3dc3e71 100644 --- a/fs/nfsd/flexfilelayoutxdr.c +++ b/fs/nfsd/flexfilelayoutxdr.c @@ -30,19 +30,24 @@ nfsd4_ff_encode_layoutget(struct xdr_stream *xdr, struct ff_idmap uid; struct ff_idmap gid; - fh_len = 4 + fl->fh.size; + fh_len = 4 + xdr_align_size(fl->fh.size); uid.len = sprintf(uid.buf, "%u", from_kuid(&init_user_ns, fl->uid)); gid.len = sprintf(gid.buf, "%u", from_kgid(&init_user_ns, fl->gid)); - /* 8 + len for recording the length, name, and padding */ - ds_len = 20 + sizeof(stateid_opaque_t) + 4 + fh_len + - 8 + uid.len + 8 + gid.len; + /* data server entry: deviceid + efficiency + stateid + fh list + + * user + group + flags + stats_collect_hint + */ + ds_len = 16 + 4 + 4 + sizeof(stateid_opaque_t) + 4 + fh_len + + 4 + xdr_align_size(uid.len) + + 4 + xdr_align_size(gid.len) + + 4 + 4; + /* mirror: ds_count + ds */ mirror_len = 4 + ds_len; - /* The layout segment */ - len = 20 + mirror_len; + /* stripe_unit + mirror_count + mirror */ + len = 12 + mirror_len; p = xdr_reserve_space(xdr, sizeof(__be32) + len); if (!p) -- 2.34.1

2 1

[PATCH OLK-6.6] nfsd: gate nfs2 setacl by argp->mask
by Lu Jialin 29 Sep '26

29 Sep '26

From: Chuck Lever <chuck.lever(a)oracle.com> stable inclusion from stable-v6.6.157 commit 8e4422b05f410f95c51b68a0db4bf1d87f6d22f5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18935 CVE: CVE-2026-89672 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a3a7e20ed66d3f04d37883c398da8a113b430769 upstream. The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode. nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFS_ACL silently strips the directory's default ACL; mask=0 strips both. This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms. Fixes: a257cdd0e217 ("[PATCH] NFSD: Add server support for NFSv3 ACLs.") Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- fs/nfsd/nfs2acl.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/fs/nfsd/nfs2acl.c b/fs/nfsd/nfs2acl.c index b21e89c0df33..90c40ee05385 100644 --- a/fs/nfsd/nfs2acl.c +++ b/fs/nfsd/nfs2acl.c @@ -115,14 +115,19 @@ static __be32 nfsacld_proc_setacl(struct svc_rqst *rqstp) inode_lock(inode); - error = set_posix_acl(&nop_mnt_idmap, fh->fh_dentry, ACL_TYPE_ACCESS, - argp->acl_access); - if (error) - goto out_drop_lock; - error = set_posix_acl(&nop_mnt_idmap, fh->fh_dentry, ACL_TYPE_DEFAULT, - argp->acl_default); - if (error) - goto out_drop_lock; + error = 0; + if (argp->mask & NFS_ACL) { + error = set_posix_acl(&nop_mnt_idmap, fh->fh_dentry, + ACL_TYPE_ACCESS, argp->acl_access); + if (error) + goto out_drop_lock; + } + if (argp->mask & NFS_DFACL) { + error = set_posix_acl(&nop_mnt_idmap, fh->fh_dentry, + ACL_TYPE_DEFAULT, argp->acl_default); + if (error) + goto out_drop_lock; + } inode_unlock(inode); -- 2.34.1

2 1

[PATCH OLK-6.6] ACPI: processor: Unregister cpufreq notifier on init failure
by Jinjie Ruan 29 Sep '26

29 Sep '26

From: Can Peng <pengcan(a)kylinos.cn> stable inclusion from stable-6.6.157 commit ccee0785030978c49505e04954eee3f30a5f01ca category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19498 CVE: CVE-2026-90364 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------ [ Upstream commit 06f32dd67e6b23a05bef0d8183c5335af91c0c3b ] acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered. Fixes: c0e0421a60bf ("ACPI: processor: Reorder acpi_processor_driver_init()") Signed-off-by: Can Peng <pengcan(a)kylinos.cn> Link: https://patch.msgid.link/20260729023605.197367-1-pengcan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/acpi/processor_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index 9dcb768fcb44..29da04ac276a 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -291,6 +291,12 @@ static int __init acpi_processor_driver_init(void) unregister_idle_drv: acpi_processor_unregister_idle_driver(); + if (acpi_processor_cpufreq_init) { + cpufreq_unregister_notifier(&acpi_processor_notifier_block, + CPUFREQ_POLICY_NOTIFIER); + acpi_processor_cpufreq_init = false; + } + return result; } -- 2.34.1

2 1

[PATCH OLK-6.6] rtc: pcf8563: fix clock provider leak on unbind
by Jinjie Ruan 29 Sep '26

29 Sep '26

From: Yi Ding <yi.s.ding(a)gmail.com> stable inclusion from stable-6.6.157 commit 7afb8db47c4f107bce89cfe5115fb31ba7c94665 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19409 CVE: CVE-2026-90126 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------ [ Upstream commit 9c48a53685040bb0de45a640b34055cbbfc69d4f ] pcf8563_clkout_register_clk() registers the CLKOUT clock provider with of_clk_add_provider(), but nothing ever unwinds it: there is no of_clk_del_provider() call and the driver has no remove callback. Each of_clk_add_provider() allocates a struct of_clk_provider, takes a reference on the OF node and adds an entry to the global of_clk_providers list, none of which is released when the device is unbound. Every bind/unbind (or module reload) therefore leaks a provider structure and an of_node reference. The clock itself is already device-managed (devm_clk_register()); only the provider registration was not. Use devm_of_clk_add_hw_provider() so the provider is removed automatically on unbind. Tie it to the parent i2c device, whose OF node carries the #clock-cells and clock-output-names properties (the RTC class device has no OF node of its own). Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Yi Ding <yi.s.ding(a)gmail.com> Link: https://patch.msgid.link/20260602035135.62264-1-yi.s.ding@gmail.com Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/rtc/rtc-pcf8563.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c index 61be91c25cf1..f524e8c1df18 100644 --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -494,7 +494,9 @@ static struct clk *pcf8563_clkout_register_clk(struct pcf8563 *pcf8563) clk = devm_clk_register(&client->dev, &pcf8563->clkout_hw); if (!IS_ERR(clk)) - of_clk_add_provider(node, of_clk_src_simple_get, clk); + devm_of_clk_add_hw_provider(pcf8563->rtc->dev.parent, + of_clk_hw_simple_get, + &pcf8563->clkout_hw); return clk; } -- 2.34.1

1 0

[PATCH OLK-6.6] ubi: Fix rollback for explicit UBI device numbers
by Lu Jialin 29 Sep '26

29 Sep '26

From: Yuho Choi <dbgh9129(a)gmail.com> stable inclusion from stable-v6.6.157 commit 552e565ed8846e7db143e4a6bdf3f5677453c686 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19443 CVE: CVE-2026-90216 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5b0a6b554e12a97f9771a9a9f4ea1f5457373c73 ] ubi_init_attach() rolls back module initialization failures by scanning ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes the parameter index matches the UBI device number. That assumption is not true when mtd= specifies an explicit ubi_num. A successfully attached device can be stored at a higher ubi_devices[] slot, and a later failure can miss it during rollback. Scan the full ubi_devices[] array and detach by the actual array index, matching the way UBI devices are stored. Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line") Signed-off-by: Yuho Choi <dbgh9129(a)gmail.com> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- drivers/mtd/ubi/build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 1a227c3b08b5..8c74020c8ce2 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1316,10 +1316,10 @@ static int __init ubi_init(void) return 0; out_detach: - for (k = 0; k < i; k++) + for (k = 0; k < UBI_MAX_DEVICES; k++) if (ubi_devices[k]) { mutex_lock(&ubi_devices_mutex); - ubi_detach_mtd_dev(ubi_devices[k]->ubi_num, 1); + ubi_detach_mtd_dev(k, 1); mutex_unlock(&ubi_devices_mutex); } ubi_debugfs_exit(); -- 2.34.1

2 1

[PATCH OLK-5.10] nvdimm/btt: reject an arena whose nfree is below the lane count
by Lu Jialin 29 Sep '26

29 Sep '26

From: Bryam Vargas <hexlabsecurity(a)proton.me> stable inclusion from stable-v5.10.270 commit eb491343d2d1784121ad9af91c25b338c28913c3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19097 CVE: CVE-2026-89965 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6a1f2e5ed9267ca19187038ac635393c165213ac upstream. The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents the nlanes = min(nfree, num_cpus) invariant, which the code does not currently honor: num_lanes is ND_MAX_LANES regardless of nfree. Reject an arena whose nfree is below num_lanes at discovery, before the per-lane arrays are allocated, enforcing that invariant. Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Cc: stable(a)vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> Reviewed-by: Alison Schofield <alison.schofield(a)intel.com> Tested-by: Alison Schofield <alison.schofield(a)intel.com> Link: https://patch.msgid.link/20260620-b4-disp-88b2514b-v1-1-3834e707d232@proton… Signed-off-by: Alison Schofield <alison.schofield(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- drivers/nvdimm/btt.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index 12ff6f8784ac..45208cdd536a 100644 --- a/drivers/nvdimm/btt.c +++ b/drivers/nvdimm/btt.c @@ -886,6 +886,14 @@ static int discover_arenas(struct btt *btt) arena->external_lba_start = cur_nlba; parse_arena_meta(arena, super, cur_off); + if (arena->nfree < btt->nd_region->num_lanes) { + dev_err(to_dev(arena), + "nfree %u smaller than lane count %d\n", + arena->nfree, btt->nd_region->num_lanes); + ret = -ENODEV; + goto out; + } + ret = log_set_indices(arena); if (ret) { dev_err(to_dev(arena), -- 2.34.1

2 1

[PATCH OLK-6.6] ACPI: processor: Unregister cpufreq notifier on init failure
by Jinjie Ruan 29 Sep '26

29 Sep '26

From: Can Peng <pengcan(a)kylinos.cn> stable inclusion from stable-6.6.157 commit ccee0785030978c49505e04954eee3f30a5f01ca category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19498 bugzilla: CVE-2026-90364 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------ [ Upstream commit 06f32dd67e6b23a05bef0d8183c5335af91c0c3b ] acpi_processor_driver_init() registers the cpufreq policy notifier before registering the ACPI processor driver and setting up CPU hotplug state. If driver_register() or cpuhp_setup_state() fails, the error path only unregisters the ACPI processor driver and the idle driver. The cpufreq notifier remains registered even though initialization failed. Mirror the module exit path on the init failure path and unregister the cpufreq notifier when it has been registered. Fixes: c0e0421a60bf ("ACPI: processor: Reorder acpi_processor_driver_init()") Signed-off-by: Can Peng <pengcan(a)kylinos.cn> Link: https://patch.msgid.link/20260729023605.197367-1-pengcan@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/acpi/processor_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c index 9dcb768fcb44..29da04ac276a 100644 --- a/drivers/acpi/processor_driver.c +++ b/drivers/acpi/processor_driver.c @@ -291,6 +291,12 @@ static int __init acpi_processor_driver_init(void) unregister_idle_drv: acpi_processor_unregister_idle_driver(); + if (acpi_processor_cpufreq_init) { + cpufreq_unregister_notifier(&acpi_processor_notifier_block, + CPUFREQ_POLICY_NOTIFIER); + acpi_processor_cpufreq_init = false; + } + return result; } -- 2.34.1

2 1

[PATCH OLK-6.6] arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry
by Jinjie Ruan 29 Sep '26

29 Sep '26

From: Will Deacon <will(a)kernel.org> mainline inclusion from mainline-v7.3-rc1 commit 88b839ce497ccb1ff92f7ae742c78dd2937ba572 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19491 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking. Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated. Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path. Cc: Kees Cook <kees(a)kernel.org> Cc: Jinjie Ruan <ruanjinjie(a)huawei.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1] Reported-by: Yiqi Sun <sunyiqixm(a)gmail.com> Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/ Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Tested-by: Jinjie Ruan <ruanjinjie(a)huawei.com> Signed-off-by: Will Deacon <will(a)kernel.org> Co-authored-by: BackportAgent(a)deepseek-v4.1-flash Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/kernel/ptrace.c | 50 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c index 9ba0bca9e166..4765eb519eb6 100644 --- a/arch/arm64/kernel/ptrace.c +++ b/arch/arm64/kernel/ptrace.c @@ -558,6 +558,42 @@ static int gpr_get(struct task_struct *target, return membuf_write(&to, uregs, sizeof(*uregs)); } +static void update_syscall_orig_x0_after_ptrace(struct task_struct *target) +{ + struct pt_regs *regs = task_pt_regs(target); + struct kernel_siginfo *info = target->last_siginfo; + + /* + * Skip the update for NO_SYSCALL (set either by the user or the + * tracer), as regs[0] holds the return value (see the comment in + * el0_svc_common()) and can be unwound using syscall_rollback(). + */ + if (regs->syscallno == NO_SYSCALL) + return; + + /* We should only be called when target is in a ptrace stop */ + if (WARN_ON_ONCE(!info)) + return; + + /* + * For compat tasks, orig_r0 is provided directly through GPR index + * 17. + */ + if (is_compat_thread(task_thread_info(target))) + return; + + /* + * Don't update orig_x0 for a syscall-exit-stop, as x0 now contains the + * return value of the system call. + */ + if ((info->si_code & ~0x80) == SIGTRAP && + target->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) { + return; + } + + regs->orig_x0 = regs->regs[0]; +} + static int gpr_set(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, const void *kbuf, const void __user *ubuf) @@ -573,6 +609,14 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset, return -EINVAL; task_pt_regs(target)->user_regs = newregs; + + /* + * Keep orig_x0 authoritative so that seccomp (via + * syscall_get_arguments()), audit and the restart path all see the same + * first argument the syscall is dispatched with, even if it has been + * updated by a tracer. + */ + update_syscall_orig_x0_after_ptrace(target); return 0; } @@ -753,6 +797,12 @@ static int system_call_set(struct task_struct *target, return ret; task_pt_regs(target)->syscallno = syscallno; + + /* + * Re-sync orig_x0 in case the syscall number has been changed + * from NO_SYSCALL. + */ + update_syscall_orig_x0_after_ptrace(target); return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] io_uring: defer eventfd signaling when queued from a wakeup handler
by Yang Erkun 28 Sep '26

28 Sep '26

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v7.3-rc1 commit cd305ee3633a45fcf5f3a5d83f99f3cb77d87b6e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18742 CVE: CVE-2026-80920 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held. eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll. Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline. Fixes: 21a091b970cd ("io_uring: signal registered eventfd to process deferred task work") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20260813133843.2933127-1-4ncienth@gmail.com/ Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: include/linux/io_uring/cmd.h io_uring/io_uring.c io_uring/poll.c [On 6.6 the IOU_F_TWQ flags live in include/linux/io_uring/cmd.h and io_eventfd_signal() lives in io_uring/io_uring.c, so add IOU_F_TWQ_IN_WAKE there and thread the defer flag through the poll wakeup paths; io_uring/{eventfd,futex,tw,waitid}.c do not exist in this tree, and io_req_local_work_add() is in io_uring.c.] Co-authored-by: BackportAgent@a:deepseek-v4.1-flash Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- include/linux/io_uring/cmd.h | 8 ++++++++ io_uring/io_uring.c | 8 ++++---- io_uring/poll.c | 21 +++++++++++---------- 3 files changed, 23 insertions(+), 14 deletions(-) diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h index cdcda6486534..58c05530442e 100644 --- a/include/linux/io_uring/cmd.h +++ b/include/linux/io_uring/cmd.h @@ -17,6 +17,14 @@ enum { * It's also ignored unless IORING_SETUP_DEFER_TASKRUN is set. */ IOU_F_TWQ_LAZY_WAKE = 1, + + /* + * Set when task_work is queued from a waitqueue wakeup handler, where + * an arbitrary provider waitqueue lock is held. Signaling the CQ ring + * eventfd inline from there can recurse back into that lock through + * epoll, so the eventfd signal must be deferred. + */ + IOU_F_TWQ_IN_WAKE = 2, }; enum io_uring_cmd_flags { diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index d0431aa9b754..63dcd425a645 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -545,7 +545,7 @@ static void io_eventfd_ops(struct rcu_head *rcu) call_rcu(&ev_fd->rcu, io_eventfd_free); } -static void io_eventfd_signal(struct io_ring_ctx *ctx) +static void io_eventfd_signal(struct io_ring_ctx *ctx, bool defer) { struct io_ev_fd *ev_fd = NULL; @@ -568,7 +568,7 @@ static void io_eventfd_signal(struct io_ring_ctx *ctx) if (ev_fd->eventfd_async && !io_wq_current_is_worker()) goto out; - if (likely(eventfd_signal_allowed())) { + if (!defer && likely(eventfd_signal_allowed())) { eventfd_signal_mask(ev_fd->cq_ev_fd, 1, EPOLL_URING_WAKE); } else { atomic_inc(&ev_fd->refs); @@ -602,7 +602,7 @@ static void io_eventfd_flush_signal(struct io_ring_ctx *ctx) if (skip) return; - io_eventfd_signal(ctx); + io_eventfd_signal(ctx, false); } void __io_commit_cqring_flush(struct io_ring_ctx *ctx) @@ -1242,7 +1242,7 @@ static inline void io_req_local_work_add(struct io_kiocb *req, unsigned flags) if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); if (ctx->has_evfd) - io_eventfd_signal(ctx); + io_eventfd_signal(ctx, flags & IOU_F_TWQ_IN_WAKE); } nr_wait = atomic_read(&ctx->cq_wait_nr); diff --git a/io_uring/poll.c b/io_uring/poll.c index 704321fbceea..9071122ef5fd 100644 --- a/io_uring/poll.c +++ b/io_uring/poll.c @@ -229,19 +229,20 @@ enum { IOU_POLL_REQUEUE = 4, }; -static void __io_poll_execute(struct io_kiocb *req, int mask) +static void __io_poll_execute(struct io_kiocb *req, int mask, unsigned tw_flags) { io_req_set_res(req, mask, 0); req->io_task_work.func = io_poll_task_func; trace_io_uring_task_add(req, mask); - io_req_task_work_add(req); + __io_req_task_work_add(req, tw_flags); } -static inline void io_poll_execute(struct io_kiocb *req, int res) +static inline void io_poll_execute(struct io_kiocb *req, int res, + unsigned tw_flags) { if (io_poll_get_ownership(req)) - __io_poll_execute(req, res); + __io_poll_execute(req, res, tw_flags); } /* @@ -358,7 +359,7 @@ void io_poll_task_func(struct io_kiocb *req, struct io_tw_state *ts) return; } else if (ret == IOU_POLL_REQUEUE) { io_kbuf_recycle(req, 0); - __io_poll_execute(req, 0); + __io_poll_execute(req, 0, 0); return; } io_poll_remove_entries(req); @@ -396,7 +397,7 @@ static void io_poll_cancel_req(struct io_kiocb *req) { io_poll_mark_cancelled(req); /* kick tw, which should complete the request */ - io_poll_execute(req, 0); + io_poll_execute(req, 0, 0); } #define IO_ASYNC_POLL_COMMON (EPOLLONESHOT | EPOLLPRI) @@ -405,7 +406,7 @@ static __cold int io_pollfree_wake(struct io_kiocb *req, struct io_poll *poll) { io_poll_mark_cancelled(req); /* we have to kick tw in case it's not already */ - io_poll_execute(req, 0); + io_poll_execute(req, 0, IOU_F_TWQ_IN_WAKE); /* * If the waitqueue is being freed early but someone is already @@ -460,7 +461,7 @@ static int io_poll_wake(struct wait_queue_entry *wait, unsigned mode, int sync, else req->flags &= ~REQ_F_SINGLE_POLL; } - __io_poll_execute(req, mask); + __io_poll_execute(req, mask, IOU_F_TWQ_IN_WAKE); } return 1; } @@ -643,7 +644,7 @@ static int __io_arm_poll_handler(struct io_kiocb *req, if (mask && (poll->events & EPOLLET) && io_poll_can_finish_inline(req, ipt)) { - __io_poll_execute(req, mask); + __io_poll_execute(req, mask, 0); return 0; } @@ -653,7 +654,7 @@ static int __io_arm_poll_handler(struct io_kiocb *req, * poll was waken up, queue up a tw, it'll deal with it. */ if (atomic_cmpxchg(&req->poll_refs, 1, 0) != 1) - __io_poll_execute(req, 0); + __io_poll_execute(req, 0, 0); } return 0; } -- 2.52.0

2 1