kernel/git/stable/linux.git/arch/s390, branch linux-rolling-stable

s390/debug: Fix deadlock during unregister

2026-09-14T11:40:44+00:00

[ Upstream commit 445c31ac638fd1af203d79bdf25fc0cb3149fbbc ] Unregistering an s390dbf debug area while one of the associated debugfs files is being written to can cause a deadlock: $ echo >.../vmur/level $ rmmod vmur =================================================== debugfs write debugfs_file_get() debug_unregister() mutex_lock(debug_mutex) debugfs_remove() wait for debugfs_file_put() debug_file_ops.write() debug_input() mutex_lock(debug_mutex) ==> DEADLOCK Fix this by splitting debug_unregister() into an s390dbf and debugfs part, and running only the s390dbf part with debug_mutex locked. Fixes: 9372a82892c2 ("s390/debug: fix debug area life cycle") Signed-off-by: Peter Oberparleiter Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

bpf, s390: Clear fetch destination on faulting arena atomic

2026-09-14T11:40:43+00:00

[ Upstream commit cc3e12330599f097f0e1f792435686ddc276f26d ] Same missing register clear as on riscv64. A RMW atomic on an arena pointer is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but bpf_jit_probe_atomic_pre() only fills in the arena base and the probe offset, leaving probe->reg at the -1 that bpf_jit_probe_init() set, which bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads back as "there is nothing to clear". That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory, but an RMW carrying BPF_FETCH also reads the old value into a register: src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for BPF_CMPXCHG. So on a fault over an unmapped arena page the program resumes at the landing pad with whatever that register held before the atomic instead of the 0 that every other BPF_PROBE_* access delivers. Fill probe->reg in from bpf_atomic_load_reg(). Unlike x86-64 and arm64, s390x does not report arena violations from its exception handler, so there is no access direction to correct here, only the missing register clear. Fixes: 2f9469484a3b ("s390/bpf: Support arena atomics") Signed-off-by: Daniel Borkmann Reviewed-by: Ilya Leoshkevich Link: https://patch.msgid.link/20260811131600.506721-5-daniel@iogearbox.net Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin

s390/irqflags: Add out-of-line definitions of arch_local_irq_*() for KMSAN

2026-09-14T11:40:38+00:00

[ Upstream commit 3f7c9f9c36b47a2a5cdbc56597eddf32662ef7fa ] Inline KMSAN arch_local_irq_*() definitions run afoul of -Wstatic-in-inline. Move them out-of-line. Make sure decompressor and non-GPL modules see the out-of-line definitions. Cc: Boqun Feng Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202607131219.euJHPSJ5-lkp@intel.com/ Suggested-by: Heiko Carstens Fixes: 1b301f5f28ba ("s390/irqflags: do not instrument arch_local_irq_*() with KMSAN") Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/vdso: Pass --eh-frame-hdr to the linker

2026-09-14T11:39:55+00:00

[ Upstream commit dc161efb6df8518b3cfa7f0a5efdc16a1aee815b ] Commit 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") accidentally broke the GNU_EH_FRAME program table entry in the vDSO, causing it to be empty: $ readelf --program-headers arch/s390/kernel/vdso/vdso.so ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align ... GNU_EH_FRAME 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x8 ... Originally, the compiler would implicitly add --eh-frame-hdr when invoking the linker, but when this Makefile was converted from invoking the linker via the compiler, to invoking it directly, the option was missed. This is the s390 variant of x86 commit cd01544a268a ("x86/vdso: Pass --eh-frame-hdr to the linker"). Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Reviewed-by: Ilya Leoshkevich Acked-by: Heiko Carstens Signed-off-by: Jens Remus Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin

s390/bpf: Replace ly instruction with llgf

2026-09-14T11:39:17+00:00

[ Upstream commit 5f6cc299938b561cb01e343bab7042611fcee12a ] cpu_nr is a 32 bit value and BPF_REG_0 is a 64 bit register, when ly loads the cpu_nr into BPF_REG_0 it does not zero the upper bits, but llgf does. Fixes: 9012cf2491e3 ("s390/bpf: Inline smp_processor_id and current_task") Signed-off-by: Maxim Khmelevskii Signed-off-by: Daniel Borkmann Reviewed-by: Ilya Leoshkevich Link: https://sashiko.dev/#/patchset/20260414142930.528751-1-max%40linux.ibm.com Link: https://lore.kernel.org/bpf/20260703125648.919196-5-max@linux.ibm.com Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin

KVM: s390: Restore sigset on error path

2026-09-11T09:51:07+00:00

commit c44d36d8e6501c4934412d9014e5e02da9efdb8f upstream. kvm_sigset_activate() installs vcpu->sigset via sigprocmask() and stashes the caller's mask in current->real_blocked; only kvm_sigset_deactivate() restores it. For KVM_RUN on a STOPPED vcpu the error path will not restore the userspace mask. Re-arrange the error handling to also restore the signal mask. Fixes: 6352e4d2dd9a3 ("KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-5-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman

KVM: s390: pv: Fix rc/rrc offset for PVM_DUMP

2026-09-11T09:51:07+00:00

commit 1e3c8e7b3465fb8a49d3623d2d0f449c0b5b48f3 upstream. The rc/rrc value is copied to the cmd location of the cmd in the kvm_pv_cmd structure. Fix the offset. Fixes: 8aba09588d2a ("KVM: s390: Add CPU dump functionality") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman

KVM: s390: keyop: use mmu_lock to read gmap->asce

2026-09-11T09:51:07+00:00

commit da07a751efa4583385f9f0f47113549fe8871242 upstream. Every other dat_* consumer in this file (kvm_s390_get_skeys, set_skeys, get_cmma_bits, set_cmma_bits, MEM_CLR_CMMA, kvm_s390_fixup_prefix, kvm_test_age_gfn, kvm_age_gfn) reads kvm->arch.gmap->asce *inside* the mmu_lock read-side. keyop is the only outlier. gmap->asce is mutated under write_lock(mmu_lock) by gmap_set_limit() and keyop might use a stale asce value for walking as KVM_S390_KEYOP and KVM_S390_VM_MEM_LIMIT_SIZE can run concurrently. This can result in memory corruption. Fixes: 0ee4ddc1647b ("KVM: s390: Storage key manipulation IOCTL") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260811153738.206885-2-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman

KVM: s390: Fix memory corruption by not reinjecting CK machine checks

2026-09-11T09:51:07+00:00

commit 546dde823a36d7283dcf46127c2f3d093443860f upstream. Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest. This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko. There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Acked-by: Heiko Carstens Acked-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260806145835.31818-1-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman

KVM: s390: Zero initialize irq in reinject_machine_check

2026-09-11T09:51:07+00:00

commit b239410c7653ff6781d4cf1d63cfc52a1bb71788 upstream. kvm_s390_reinject_machine_check() fills cr14, mcic, ext_damage_code and failing_storage_address of the on-stack struct kvm_s390_irq, but struct kvm_s390_mchk_info also has a pad word and a 16 byte fixed_logout array. struct mcck_volatile_info carries no logout data, so there is nothing to copy there and both stay whatever was on the stack. __inject_mchk() then memcpy()s fixed_logout into the vcpu local interrupt state unconditionally. This will reach the guest during deliver and userspace during migration. Reflecting zeroes is the correct behaviour here, as KVM has no logout data for a reinjected machine check. This needs a host machine check while the cpu is in SIE so not trivial to trigger. Fixes: 4d62fcc0b692 ("KVM: s390: Inject machine check into the guest") Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger Reviewed-by: Matthew Rosato Reviewed-by: Claudio Imbrenda Signed-off-by: Claudio Imbrenda Message-ID: <20260805110455.7200-4-borntraeger@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman