Linux kernel stable tree https://git.landau.one/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master 2026-09-06T03:45:18+00:00 2026-09-06T03:45:18+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-09-06T03:45:18+00:00 urn:sha1:1fc5a74b108fc90951890ec513ac81869f5eaff1 Pull kmalloc_obj conversions from Kees Cook: "Another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci" * tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: refresh kmalloc_obj() conversions drm/amd/display: Fix harmless type mismatch in allocation 2026-09-05T04:37:00+00:00 Kees Cook kees+treewide@kernel.org 2026-09-02T22:31:14+00:00 urn:sha1:3a2c4d55e32ad65efebdb6de44eef3bfa08bb49d This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org> 2026-09-04T13:45:13+00:00 Tao Cui cuitao@kylinos.cn 2026-09-04T13:45:13+00:00 urn:sha1:9296375902579f9b0e456bbb76e5cf179e5a4e0b In kvm_loongarch_cpucfg_set_attr() the check-then-set on kvm->arch.pv_features is lockless, so two vCPUs can race past the validation and set different values. Add a spinlock to protect it. Cc: stable@vger.kernel.org Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:45:13+00:00 Zeng Chi zengchi@kylinos.cn 2026-09-04T13:45:13+00:00 urn:sha1:501514d6ebd2111c353a1296f25dbe22fbd64657 pch_msi_set_irq() passes e->msi.data straight into eiointc_set_irq() as the irq number. The MSI data comes from userspace, that either via a KVM_IRQ_ROUTING_MSI entry set with KVM_SET_GSI_ROUTING (used by irqfd and KVM_IRQ_LINE) or directly via KVM_SIGNAL_MSI, and is never checked against EIOINTC_IRQS. eiointc_set_irq() uses the value with __set_bit()/__clear_bit() on the 256-bit isr bitmap, eiointc_update_irq() then indexes sw_coremap[] and the per-cpu coreisr/sw_coreisr bitmaps with it. Therefore a data value >= 256 reads and writes memory past the end of those arrays, i.e. any process holding a VM fd can corrupt kernel memory beyond the allocation of loongarch_eiointc. Reject MSI data that doesn't fit in the EIOINTC irq space. The DMSINTC path is unaffected as it decodes the vector from the address and masks it. Cc: stable@vger.kernel.org Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260531140921.1B1181F00893@smtp.kernel.org/ Reviewed-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Zeng Chi <zengchi@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:45:13+00:00 Zeng Chi zengchi@kylinos.cn 2026-09-04T13:45:13+00:00 urn:sha1:27a9bfee3bbcb3cabb77797354f07e0e44e49831 kvm_arch_prepare_memory_region() computes new->arch.flags, i.e. whether a memslot is KVM_MEM_HUGEPAGE_CAPABLE or KVM_MEM_HUGEPAGE_INCAPABLE, only for KVM_MR_CREATE and KVM_MR_MOVE, and returns early for every other change. But the generic code allocates a zeroed memslot for every change and never copies old->arch, so after a KVM_MR_FLAGS_ONLY update, e.g. toggling KVM_MEM_LOG_DIRTY_PAGES for live migration, the active memslot has arch.flags == 0. With both flags clear, fault_supports_huge_mapping() falls through to the alignment check on the HVA range alone, which no longer verifies that the GPA and HVA have the same offset within a PMD. A memslot that was marked KVM_MEM_HUGEPAGE_INCAPABLE because of a GPA/HVA offset mismatch can then be mapped with PMD entries on read faults, and since kvm_map_page() aligns the gfn and the pfn independently, the guest ends up accessing the wrong host pages, exactly the "d -> f, e -> g" case described in the comment above the check. Carry the arch flags over from the old memslot for KVM_MR_FLAGS_ONLY, as the GPA, HVA and size are guaranteed to be unchanged for that case. Cc: stable@vger.kernel.org Fixes: 7ab6fb505b2a ("LoongArch: KVM: Optimization for memslot hugepage checking") Tested-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Zeng Chi <zengchi@kylinos.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:44:54+00:00 Bibo Mao maobibo@loongson.cn 2026-09-04T13:44:54+00:00 urn:sha1:40bdbb4bfa730400e8b383d6f5931f90aebb5f54 Function kvm_arch_flush_remote_tlbs_memslot() is not called any more, so remove this API. Reviewed-by: Tao Cui <cuitao@kylinos.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:44:54+00:00 Chaithanya Lagisetty nagachaithanya9911@gmail.com 2026-09-04T13:44:54+00:00 urn:sha1:910132bc7d72f26a8b288c2a38c32445a48d5be0 kvm_loongarch_env_init() allocates the per-CPU kvm_context (vmcs) and kvm_loongarch_ops, registers the perf callbacks, and then registers the IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices. If any of those device registrations fails, the function returned the error directly, leaving everything acquired so far in place: vmcs and kvm_loongarch_ops are never freed, the perf callbacks stay registered, and all previously registered KVM device operations remain registered. kvm_loongarch_init() propagates the errors without calling kvm_loongarch_env_exit(), so nothing else cleans up either. Unwind the error path in reverse order of registration, so that each failure only undoes what had actually been set up. Use the same helpers in kvm_loongarch_env_exit() to remove the device registrations during normal teardown as well. Cc: stable@vger.kernel.org Fixes: c532de5a67a7 ("LoongArch: KVM: Add IPI device support") Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:44:53+00:00 Chaithanya Lagisetty nagachaithanya9911@gmail.com 2026-09-04T13:44:53+00:00 urn:sha1:4af22177032ab2357bf551fbfcdebc8fd9f2502d The IPI/EIOINTC/PCH-PIC/DMSINTC KVM devices each have a helper that registers their kvm_device_ops, but there is no counterpart to remove them, so a caller that needs to undo a registration has to open-code kvm_unregister_device_ops() with the matching device type. Add kvm_loongarch_unregister_{ipi,eiointc,pch_pic,dmsintc}_device() next to the existing register helpers. kvm_unregister_device_ops() is a no-op when the corresponding device type is not currently registered. No functional change, as there are no callers yet. Cc: stable@vger.kernel.org Suggested-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:44:53+00:00 Chaithanya Lagisetty nagachaithanya9911@gmail.com 2026-09-04T13:44:53+00:00 urn:sha1:f7a1064cce3b100b54780c68529176232d8eb01e kvm_loongarch_init() calls kvm_loongarch_env_init() to allocate the per-CPU kvm_context (vmcs) and kvm_loongarch_ops and to register the perf callbacks, and then calls kvm_init(). If kvm_init() fails its result is returned directly, but since module_init() does not run the module_exit() stuff on failure, so kvm_loongarch_env_exit() is never called and those resources are leaked. So call kvm_loongarch_env_exit() when kvm_init() fails, matching the teardown-on-failure pattern used by riscv_kvm_init(). Cc: stable@vger.kernel.org Fixes: 2bd6ac687261 ("LoongArch: KVM: Implement kvm module related interface") Reviewed-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Chaithanya Lagisetty <nagachaithanya9911@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> 2026-09-04T13:44:43+00:00 Tiezhu Yang yangtiezhu@loongson.cn 2026-09-04T13:44:43+00:00 urn:sha1:30419a0aa128135a81be917eaa3bd2f1a10c9ca3 In the LoongArch BPF JIT code, the branch offset represents the number of instructions. An offset of 1 means the target of the "beq" is the current PC plus 1 instruction (PC + 4 bytes). This matches the exact same path as the sequential non-branch execution, the "or" instruction is always executed for the cast_user JIT arm in build_insn(). If the pointer is not NULL, there is no side effect. But if the pointer is NULL, it is incorrectly combined with the base address and turns into a non-zero address, meaning a zero arena offset no longer casts to NULL. Fix this by changing the branch offset from 1 to 2, which properly skips the "or" instruction and jumps directly to the "move_reg" instruction if the pointer is NULL, ensuring the destination register is safely cleared to 0. Cc: stable@vger.kernel.org Fixes: 4fdb5dd8aeba ("LoongArch: BPF: Implement bpf_addr_space_cast instruction") Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>