- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA
by Jinjie Ruan 06 Feb '26

06 Feb '26

From: Mark Rutland <mark.rutland(a)arm.com> stable inclusion from stable-v6.6.122 commit 19b2c3f3ca1b4b6dccd2a42aca2692d8c79c4214 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13639 CVE: CVE-2026-23107 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ea8ccfddbce0bee6310da4f3fc560ad520f5e6b4 upstream. The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sve_state is NULL. In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that sve_state had been allocated previously. In these cases, userspace can enter streaming mode without trapping while sve_state is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Fix this by having restore_za_context() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed. Fixes: 39782210eb7e ("arm64/sme: Implement ZA signal handling") Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Cc: <stable(a)vger.kernel.org> Cc: Mark Brown <broonie(a)kernel.org> Cc: Will Deacon <will(a)kernel.org> Reviewed-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/arm64/kernel/signal.c [conflict because ce514000da4f ("arm64/sme: Rename za_state to sme_state")] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/kernel/signal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index a0c85bb01751..d8c9434f975e 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -363,6 +363,10 @@ int restore_za_context(struct user_ctxs *user) fpsimd_flush_task_state(current); /* From now, fpsimd_thread_switch() won't touch thread.sve_state */ + sve_alloc(current, false); + if (!current->thread.sve_state) + return -ENOMEM; + sme_alloc(current, true); if (!current->thread.za_state) { current->thread.svcr &= ~SVCR_ZA_MASK; -- 2.34.1

2 1

[PATCH OLK-6.6] x86/CPU/AMD: Add RDSEED fix for Zen5
by Bowen You 06 Feb '26

06 Feb '26

From: Gregory Price <gourry(a)gourry.net> stable inclusion from stable-v6.12.57 commit e980de2ff109dacb6d9d3a77f01b27c467115ecb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11500 CVE: CVE-2025-68313 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 607b9fb2ce248cc5b633c5949e0153838992c152 upstream. There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ] Cc: stable(a)vger.kernel.org Signed-off-by: Gregory Price <gourry(a)gourry.net> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Link: https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net [ bp: 6.12 backport: use the alternative microcode version checking. ] Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: arch/x86/include/asm/cpu.h [Add the definition of zen_patch_rev] Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- arch/x86/kernel/cpu/amd.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index f89dbe6f48e6..5a46bf0cce5d 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1135,8 +1135,43 @@ static void init_amd_zen4(struct cpuinfo_x86 *c) } } +static bool check_rdseed_microcode(void) +{ + struct cpuinfo_x86 *c = &boot_cpu_data; + union zen_patch_rev p; + u32 min_rev = 0; + + p.ext_fam = c->x86 - 0xf; + p.model = c->x86_model; + p.ext_model = c->x86_model >> 4; + p.stepping = c->x86_stepping; + /* reserved bits are expected to be 0 in test below */ + p.__reserved = 0; + + if (cpu_has(c, X86_FEATURE_ZEN5)) { + switch (p.ucode_rev >> 8) { + case 0xb0021: min_rev = 0xb00215a; break; + case 0xb1010: min_rev = 0xb101054; break; + default: + pr_debug("%s: ucode_rev: 0x%x, current revision: 0x%x\n", + __func__, p.ucode_rev, c->microcode); + return false; + } + } + + if (!min_rev) + return false; + + return c->microcode >= min_rev; +} + static void init_amd_zen5(struct cpuinfo_x86 *c) { + if (!check_rdseed_microcode()) { + clear_cpu_cap(c, X86_FEATURE_RDSEED); + msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18); + pr_emerg_once("RDSEED32 is broken. Disabling the corresponding CPUID bit.\n"); + } } static void init_amd(struct cpuinfo_x86 *c) -- 2.34.1

2 1

[PATCH OLK-5.10] irqchip/gic-v3-its: Avoid truncating memory addresses
by Jinjie Ruan 06 Feb '26

06 Feb '26

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v6.6.122 commit 1b323391560354d8c515de8658b057a1daa82adb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13618 CVE: CVE-2026-23085 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8d76a7d89c12d08382b66e2f21f20d0627d14859 upstream. On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260119201603.2713066-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/irqchip/irq-gic-v3-its.c [ conflict becasue 5ddbc909f82a ("[Backport] irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1") not merged. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index fbe83b657dcc..8cac29a0996c 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -954,7 +954,7 @@ static struct its_collection *its_build_mapd_cmd(struct its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long itt_addr; + phys_addr_t itt_addr; u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); @@ -1184,7 +1184,7 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long vpt_addr, vconf_addr; + phys_addr_t vpt_addr, vconf_addr; u64 target; bool alloc; @@ -2891,10 +2891,10 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser, baser->psz = psz; tmp = indirect ? GITS_LVL1_ENTRY_SIZE : esz; - pr_info("ITS@%pa: allocated %d %s @%lx (%s, esz %d, psz %dK, shr %d)\n", + pr_info("ITS@%pa: allocated %d %s @%llx (%s, esz %d, psz %dK, shr %d)\n", &its->phys_base, (int)(PAGE_ORDER_TO_SIZE(order) / (int)tmp), its_base_type_string[type], - (unsigned long)virt_to_phys(base), + (u64)virt_to_phys(base), indirect ? "indirect" : "flat", (int)esz, psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT); -- 2.34.1

2 1

[PATCH OLK-6.6] irqchip/gic-v3-its: Avoid truncating memory addresses
by Jinjie Ruan 06 Feb '26

06 Feb '26

From: Arnd Bergmann <arnd(a)arndb.de> stable inclusion from stable-v6.6.122 commit 1b323391560354d8c515de8658b057a1daa82adb category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13618 CVE: CVE-2026-23085 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 8d76a7d89c12d08382b66e2f21f20d0627d14859 upstream. On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260119201603.2713066-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/irqchip/irq-gic-v3-its.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index c8e327f96303..a9802a3870db 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -978,7 +978,7 @@ static struct its_collection *its_build_mapd_cmd(struct its_node *its, struct its_cmd_block *cmd, struct its_cmd_desc *desc) { - unsigned long itt_addr; + phys_addr_t itt_addr; u8 size = ilog2(desc->its_mapd_cmd.dev->nr_ites); itt_addr = virt_to_phys(desc->its_mapd_cmd.dev->itt); @@ -1208,7 +1208,7 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, struct its_cmd_desc *desc) { struct its_vpe *vpe = valid_vpe(its, desc->its_vmapp_cmd.vpe); - unsigned long vpt_addr, vconf_addr; + phys_addr_t vpt_addr, vconf_addr; u64 target; bool alloc; @@ -2836,10 +2836,10 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser, baser->psz = psz; tmp = indirect ? GITS_LVL1_ENTRY_SIZE : esz; - pr_info("ITS@%pa: allocated %d %s @%lx (%s, esz %d, psz %dK, shr %d)\n", + pr_info("ITS@%pa: allocated %d %s @%llx (%s, esz %d, psz %dK, shr %d)\n", &its->phys_base, (int)(PAGE_ORDER_TO_SIZE(order) / (int)tmp), its_base_type_string[type], - (unsigned long)virt_to_phys(base), + (u64)virt_to_phys(base), indirect ? "indirect" : "flat", (int)esz, psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT); -- 2.34.1

2 1

[PATCH OLK-6.6 00/10] fix CVE-2024-50102
by Qi Xi 06 Feb '26

06 Feb '26

*** BLURB HERE *** David Gow (1): x86/uaccess: Zero the 8-byte get_range case on failure on 32-bit David Laight (1): x86: fix off-by-one in access_ok() Linus Torvalds (6): runtime constants: deal with old decrepit linkers runtime constants: add x86 architecture support x86: fix whitespace in runtime-const assembler output x86/uaccess: Improve the 8-byte getuser() case x86: fix user address masking non-canonical speculation issue x86: uaccess: don't use runtime-const rewriting in modules Stephen Brennan (1): dcache: keep dentry_hashtable or d_hash_shift even when not used Thomas Gleixner (1): x86/uaccess: Add missing __force to casts in __access_ok() and valid_user_address() arch/x86/include/asm/runtime-const.h | 65 ++++++++++++++++++++++ arch/x86/include/asm/uaccess_64.h | 49 ++++++++++------- arch/x86/kernel/cpu/common.c | 14 +++++ arch/x86/kernel/vmlinux.lds.S | 4 ++ arch/x86/lib/getuser.S | 80 ++++++++++------------------ fs/dcache.c | 9 +++- include/asm-generic/vmlinux.lds.h | 7 +++ 7 files changed, 157 insertions(+), 71 deletions(-) create mode 100644 arch/x86/include/asm/runtime-const.h -- 2.33.0

2 11

[PATCH OLK-5.10 0/1] CVE-2023-53712
by Liu Mingrui 06 Feb '26

06 Feb '26

From: Mingrui Liu <liumingrui(a)huawei.com> CVE-2023-53712 Mårten Lindahl (1): ARM: 9317/1: kexec: Make smp stop calls asynchronous arch/arm/kernel/machine_kexec.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6 00/17] backport some net bugfix from 6.6 lts
by Zhang Changzhong 06 Feb '26

06 Feb '26

Alexey Simakov (1): sctp: avoid NULL dereference when chunk data buffer is missing Eric Dumazet (2): sctp: initialize more fields in sctp_v6_from_sk() sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto Hans de Goede (1): net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Ido Schimmel (1): nexthop: Forbid FDB status change while nexthop is in a group Ilya Dryomov (1): libceph: fix potential use-after-free in have_mon_and_osd_map() Kuniyuki Iwashima (3): tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). tipc: Fix use-after-free in tipc_mon_reinit_self(). tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). Paul Chaignon (1): bpf: Explicitly check accesses to bpf_sock_addr Slavin Liu (1): ipvs: Defer ip_vs_ftp unregister during netns cleanup Stefan Wiehler (3): sctp: Hold RCU read lock while iterating over address list sctp: Prevent TOCTOU out-of-bounds write sctp: Hold sock lock while iterating over address list Wang Liang (1): netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm ziming zhang (2): libceph: prevent potential out-of-bounds writes in handle_auth_session_key() libceph: replace BUG_ON with bounds check for map->max_osd net/bridge/br_netfilter_hooks.c | 3 --- net/ceph/auth_x.c | 2 ++ net/ceph/ceph_common.c | 53 +++++++++++++++++++++++++---------------- net/ceph/debugfs.c | 14 +++++++---- net/ceph/osdmap.c | 18 ++++++++------ net/core/filter.c | 16 ++++++++----- net/ipv4/nexthop.c | 7 ++++++ net/ipv4/tcp.c | 5 ++++ net/ipv4/tcp_input.c | 1 - net/netfilter/ipvs/ip_vs_ftp.c | 4 +++- net/rfkill/rfkill-gpio.c | 4 ++-- net/sctp/diag.c | 21 ++++++++++++---- net/sctp/inqueue.c | 13 +++++----- net/sctp/ipv6.c | 2 ++ net/sctp/transport.c | 13 ++++++---- net/tipc/net.c | 2 ++ 16 files changed, 118 insertions(+), 60 deletions(-) -- 2.9.5

2 18

[PATCH OLK-6.6] pNFS: Fix a deadlock when returning a delegation during open()
by Li Lingfeng 06 Feb '26

06 Feb '26

From: Trond Myklebust <trond.myklebust(a)hammerspace.com> mainline inclusion from mainline-v6.19-rc6 commit 857bf9056291a16785ae3be1d291026b2437fc48 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13583 CVE: CVE-2026-23050 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935 The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given. The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation. Reported-by: Benjamin Coddington <bcodding(a)hammerspace.com> Fixes: 29ade5db1293 ("pNFS: Wait on outstanding layoutreturns to complete in pnfs_roc()") Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> Conflicts: fs/nfs/pnfs.c [Commit 5468fc8298a9 ("NFSv4/pNFS: Do layout state recovery upon reboot") add definition of pnfs_layout_return_on_reboot() before pnfs_roc().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 6 ++--- fs/nfs/pnfs.c | 58 +++++++++++++++++++++++++++++++++-------------- fs/nfs/pnfs.h | 17 ++++++-------- 3 files changed, 51 insertions(+), 30 deletions(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 4410e2ad8f39..54ce1f41eb53 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -3783,8 +3783,8 @@ int nfs4_do_close(struct nfs4_state *state, gfp_t gfp_mask, int wait) calldata->res.seqid = calldata->arg.seqid; calldata->res.server = server; calldata->res.lr_ret = -NFS4ERR_NOMATCHING_LAYOUT; - calldata->lr.roc = pnfs_roc(state->inode, - &calldata->lr.arg, &calldata->lr.res, msg.rpc_cred); + calldata->lr.roc = pnfs_roc(state->inode, &calldata->lr.arg, + &calldata->lr.res, msg.rpc_cred, wait); if (calldata->lr.roc) { calldata->arg.lr_args = &calldata->lr.arg; calldata->res.lr_res = &calldata->lr.res; @@ -6729,7 +6729,7 @@ static int _nfs4_proc_delegreturn(struct inode *inode, const struct cred *cred, data->inode = nfs_igrab_and_active(inode); if (data->inode || issync) { data->lr.roc = pnfs_roc(inode, &data->lr.arg, &data->lr.res, - cred); + cred, issync); if (data->lr.roc) { data->args.lr_args = &data->lr.arg; data->res.lr_res = &data->lr.res; diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c index 0737d9a15d86..6dbfae295f76 100644 --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -1426,10 +1426,9 @@ pnfs_commit_and_return_layout(struct inode *inode) return ret; } -bool pnfs_roc(struct inode *ino, - struct nfs4_layoutreturn_args *args, - struct nfs4_layoutreturn_res *res, - const struct cred *cred) +bool pnfs_roc(struct inode *ino, struct nfs4_layoutreturn_args *args, + struct nfs4_layoutreturn_res *res, const struct cred *cred, + bool sync) { struct nfs_inode *nfsi = NFS_I(ino); struct nfs_open_context *ctx; @@ -1440,7 +1439,7 @@ bool pnfs_roc(struct inode *ino, nfs4_stateid stateid; enum pnfs_iomode iomode = 0; bool layoutreturn = false, roc = false; - bool skip_read = false; + bool skip_read; if (!nfs_have_layout(ino)) return false; @@ -1453,20 +1452,14 @@ bool pnfs_roc(struct inode *ino, lo = NULL; goto out_noroc; } - pnfs_get_layout_hdr(lo); - if (test_bit(NFS_LAYOUT_RETURN_LOCK, &lo->plh_flags)) { - spin_unlock(&ino->i_lock); - rcu_read_unlock(); - wait_on_bit(&lo->plh_flags, NFS_LAYOUT_RETURN, - TASK_UNINTERRUPTIBLE); - pnfs_put_layout_hdr(lo); - goto retry; - } /* no roc if we hold a delegation */ + skip_read = false; if (nfs4_check_delegation(ino, FMODE_READ)) { - if (nfs4_check_delegation(ino, FMODE_WRITE)) + if (nfs4_check_delegation(ino, FMODE_WRITE)) { + lo = NULL; goto out_noroc; + } skip_read = true; } @@ -1475,12 +1468,43 @@ bool pnfs_roc(struct inode *ino, if (state == NULL) continue; /* Don't return layout if there is open file state */ - if (state->state & FMODE_WRITE) + if (state->state & FMODE_WRITE) { + lo = NULL; goto out_noroc; + } if (state->state & FMODE_READ) skip_read = true; } + if (skip_read) { + bool writes = false; + + list_for_each_entry(lseg, &lo->plh_segs, pls_list) { + if (lseg->pls_range.iomode != IOMODE_READ) { + writes = true; + break; + } + } + if (!writes) { + lo = NULL; + goto out_noroc; + } + } + + pnfs_get_layout_hdr(lo); + if (test_bit(NFS_LAYOUT_RETURN_LOCK, &lo->plh_flags)) { + if (!sync) { + pnfs_set_plh_return_info( + lo, skip_read ? IOMODE_RW : IOMODE_ANY, 0); + goto out_noroc; + } + spin_unlock(&ino->i_lock); + rcu_read_unlock(); + wait_on_bit(&lo->plh_flags, NFS_LAYOUT_RETURN, + TASK_UNINTERRUPTIBLE); + pnfs_put_layout_hdr(lo); + goto retry; + } list_for_each_entry_safe(lseg, next, &lo->plh_segs, pls_list) { if (skip_read && lseg->pls_range.iomode == IOMODE_READ) @@ -1520,7 +1544,7 @@ bool pnfs_roc(struct inode *ino, out_noroc: spin_unlock(&ino->i_lock); rcu_read_unlock(); - pnfs_layoutcommit_inode(ino, true); + pnfs_layoutcommit_inode(ino, sync); if (roc) { struct pnfs_layoutdriver_type *ld = NFS_SERVER(ino)->pnfs_curr_ld; if (ld->prepare_layoutreturn) diff --git a/fs/nfs/pnfs.h b/fs/nfs/pnfs.h index 79996d7dad0f..a613466f6f22 100644 --- a/fs/nfs/pnfs.h +++ b/fs/nfs/pnfs.h @@ -295,10 +295,9 @@ int pnfs_mark_matching_lsegs_return(struct pnfs_layout_hdr *lo, u32 seq); int pnfs_mark_layout_stateid_invalid(struct pnfs_layout_hdr *lo, struct list_head *lseg_list); -bool pnfs_roc(struct inode *ino, - struct nfs4_layoutreturn_args *args, - struct nfs4_layoutreturn_res *res, - const struct cred *cred); +bool pnfs_roc(struct inode *ino, struct nfs4_layoutreturn_args *args, + struct nfs4_layoutreturn_res *res, const struct cred *cred, + bool sync); int pnfs_roc_done(struct rpc_task *task, struct nfs4_layoutreturn_args **argpp, struct nfs4_layoutreturn_res **respp, int *ret); void pnfs_roc_release(struct nfs4_layoutreturn_args *args, @@ -769,12 +768,10 @@ pnfs_layoutcommit_outstanding(struct inode *inode) return false; } - -static inline bool -pnfs_roc(struct inode *ino, - struct nfs4_layoutreturn_args *args, - struct nfs4_layoutreturn_res *res, - const struct cred *cred) +static inline bool pnfs_roc(struct inode *ino, + struct nfs4_layoutreturn_args *args, + struct nfs4_layoutreturn_res *res, + const struct cred *cred, bool sync) { return false; } -- 2.52.0

2 1

[PATCH OLK-6.6] Input: alps - fix use-after-free bugs caused by dev3_register_work
by Xia Fukun 06 Feb '26

06 Feb '26

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.19-rc2 commit bf40644ef8c8a288742fa45580897ed0e0289474 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13374 CVE: CVE-2025-68822 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The dev3_register_work delayed work item is initialized within alps_reconnect() and scheduled upon receipt of the first bare PS/2 packet from an external PS/2 device connected to the ALPS touchpad. During device detachment, the original implementation calls flush_workqueue() in psmouse_disconnect() to ensure completion of dev3_register_work. However, the flush_workqueue() in psmouse_disconnect() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after flush_workqueue() has finished executing, the dev3_register_work could still be scheduled. Although the psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(), the scheduling of dev3_register_work remains unaffected. The race condition can occur as follows: CPU 0 (cleanup path) | CPU 1 (delayed work) psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USE Add disable_delayed_work_sync() in alps_disconnect() to ensure that dev3_register_work is properly canceled and prevented from executing after the alps_data structure has been deallocated. This bug is identified by static analysis. Fixes: 04aae283ba6a ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") Cc: stable(a)kernel.org Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Link: https://patch.msgid.link/b57b0a9ccca51a3f06be141bfc02b9ffe69d1845.176593939… Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/input/mouse/alps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c index e2c11d9f3868..4952fca027d9 100644 --- a/drivers/input/mouse/alps.c +++ b/drivers/input/mouse/alps.c @@ -2971,6 +2971,7 @@ static void alps_disconnect(struct psmouse *psmouse) psmouse_reset(psmouse); timer_shutdown_sync(&priv->timer); + disable_delayed_work_sync(&priv->dev3_register_work); if (priv->dev2) input_unregister_device(priv->dev2); if (!IS_ERR_OR_NULL(priv->dev3)) -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] CVE-2023-53712
by Liu Mingrui 06 Feb '26

06 Feb '26

From: Mingrui Liu <liumingrui(a)huawei.com> CVE-2023-53712 Mårten Lindahl (1): ARM: 9317/1: kexec: Make smp stop calls asynchronous arch/arm/kernel/machine_kexec.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) -- 2.34.1

2 2