kernel/linux.git/arch, branch v6.19.3

LoongArch: Rework KASAN initialization for PTW-enabled systems

2026-02-19T15:33:24+00:00

commit 5ec5ac4ca27e4daa234540ac32f9fc5219377d53 upstream. kasan_init_generic() indicates that kasan is fully initialized, so it should be put at end of kasan_init(). Otherwise bringing up the primary CPU failed when CONFIG_KASAN is set on PTW-enabled systems, here are the call chains: kernel_entry() start_kernel() setup_arch() kasan_init() kasan_init_generic() The reason is PTW-enabled systems have speculative accesses which means memory accesses to the shadow memory after kasan_init() may be executed by hardware before. However, accessing shadow memory is safe only after kasan fully initialized because kasan_init() uses a temporary PGD table until we have populated all levels of shadow page tables and writen the PGD register. Moving kasan_init_generic() later can defer the occasion of kasan_enabled(), so as to avoid speculative accesses on shadow pages. After moving kasan_init_generic() to the end, kasan_init() can no longer call kasan_mem_to_shadow() for shadow address conversion because it will always return kasan_early_shadow_page. On the other hand, we should keep the current logic of kasan_mem_to_shadow() for both the early and final stage because there may be instrumentation before kasan_init(). To solve this, we factor out a new mem_to_shadow() function from current kasan_mem_to_shadow() for the shadow address conversion in kasan_init(). Cc: stable@vger.kernel.org Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman

arm64: dts: mediatek: mt8183: Add missing endpoint IDs to display graph

2026-02-19T15:33:24+00:00

commit be0b304eeb8c5f77e4f98f64e58729d879195f2f upstream. The endpoint IDs in the display graph are expected to match the associated display path number, i.e. all endpoints connected to mmsys_ep_main must have reg = <0> and all endpoints connected to mmsys_ep_ext must have reg = <1>. Add the missing ID to all endpoints in the display graph, based on mt8365.dtsi as an existing example that does this correctly. Fixes: e72d63fa0563 ("arm64: dts: mediatek: mt8183: Migrate to display controller OF graph") Reported-by: Evans Jahja Closes: https://lore.kernel.org/linux-mediatek/CAAq5pW9o3itC0G16LnJO7KMAQ_XoqXUpB=cuJ_7e3-H11zKd5Q@mail.gmail.com/ Tested-by: Chen-Yu Tsai Signed-off-by: Otto Pflüger [Angelo: Fixed dtbs_check issues] Signed-off-by: AngeloGioacchino Del Regno Cc: Thorsten Leemhuis Signed-off-by: Greg Kroah-Hartman

x86/vmware: Fix hypercall clobbers

2026-02-06T22:51:03+00:00

Fedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ... because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in. The QEMU vmmouse driver saves and restores the register state in a "uint32_t data[6];" and as a result restores the state with the high bits all cleared. RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced. The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall. In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmware_hypercall3() and vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls. Reported-by: Justin Forbes Link: https://lore.kernel.org/all/99a9c69a-fc1a-43b7-8d1e-c42d6493b41f@broadcom.com/ Signed-off-by: Josh Poimboeuf Cc: stable@kernel.org Signed-off-by: Linus Torvalds

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux

2026-02-06T17:21:38+00:00

Pull ARM fix from Russell King: "Just one fix for memset64() on big endian 32-bit ARM systems" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9468/1: fix memset64() on big-endian

Merge tag 'mm-hotfixes-stable-2026-02-04-15-55' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2026-02-05T00:04:00+00:00

Pull misc fixes from Andrew Morton: "Five hotfixes. Two are cc:stable, two are for MM. All are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-02-04-15-55' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: Documentation: document liveupdate cmdline parameter mm, shmem: prevent infinite loop on truncate race mailmap: update Alexander Mikhalitsyn's emails liveupdate: luo_file: do not clear serialized_data on unfreeze x86/kfence: fix booting on 32bit non-PAE systems

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2026-02-04T18:38:56+00:00

Pull KVM fixes from Paolo Bonzini: - Fix a bug where AVIC is incorrectly inhibited when running with x2AVIC disabled via module param (or on a system without x2AVIC) - Fix a dangling device posted IRQs bug by explicitly checking if the irqfd is still active (on the list) when handling an eventfd signal, instead of zeroing the irqfd's routing information when the irqfd is deassigned. Zeroing the irqfd's routing info causes arm64 and x86's to not disable posting for the IRQ (kvm_arch_irq_bypass_del_producer() looks for an MSI), incorrectly leaving the IRQ in posted mode (and leading to use-after-free and memory leaks on AMD in particular). This is both the most pressing and scariest, but it's been in -next for a while. - Disable FORTIFY_SOURCE for KVM selftests to prevent the compiler from generating calls to the checked versions of memset() and friends, which leads to unexpected page faults in guest code due e.g. __memset_chk@plt not being resolved. - Explicitly configure the supported XSS capabilities from within {svm,vmx}_set_cpu_caps() to fix a bug where VMX will compute the reference VMCS configuration with SHSTK and IBT enabled, but then compute each CPUs local config with SHSTK and IBT disabled if not all CET xfeatures are enabled, e.g. if the kernel is built with X86_KERNEL_IBT=n. The mismatch in features results in differing nVMX setting, and ultimately causes kvm-intel.ko to refuse to load with nested=1. * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: Explicitly configure supported XSS from {svm,vmx}_set_cpu_caps() KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures KVM: x86: Assert that non-MSI doesn't have bypass vCPU when deleting producer KVM: Don't clobber irqfd routing type when deassigning irqfd KVM: SVM: Check vCPU ID against max x2AVIC ID if and only if x2AVIC is enabled

Merge tag 'kvm-x86-fixes-6.19-rc8' of https://github.com/kvm-x86/linux into HEAD

2026-02-04T17:30:32+00:00

Final KVM fixes for 6.19: - Fix a bug where AVIC is incorrectly inhibited when running with x2AVIC disabled via module param (or on a system without x2AVIC). - Fix a dangling device posted IRQs bug by explicitly checking if the irqfd is still active (on the list) when handling an eventfd signal, instead of zeroing the irqfd's routing information when the irqfd is deassigned. Zeroing the irqfd's routing info causes arm64 and x86's to not disable posting for the IRQ (kvm_arch_irq_bypass_del_producer() looks for an MSI), incorrectly leaving the IRQ in posted mode (and leading to use-after-free and memory leaks on AMD in particular). This is both the most pressing and scariest, but it's been in -next for a while. - Disable FORTIFY_SOURCE for KVM selftests to prevent the compiler from generating calls to the checked versions of memset() and friends, which leads to unexpected page faults in guest code due e.g. __memset_chk@plt not being resolved. - Explicitly configure the support XSS from within {svm,vmx}_set_cpu_caps() to fix a bug where VMX will compute the reference VMCS configuration with SHSTK and IBT enabled, but then compute each CPUs local config with SHSTK and IBT disabled if not all CET xfeatures are enabled, e.g. if the kernel is built with X86_KERNEL_IBT=n. The mismatch in features results in differing nVMX setting, and ultimately causes kvm-intel.ko to refuse to load with nested=1.

x86/kfence: fix booting on 32bit non-PAE systems

2026-02-03T02:43:55+00:00

The original patch inverted the PTE unconditionally to avoid L1TF-vulnerable PTEs, but Linux doesn't make this adjustment in 2-level paging. Adjust the logic to use the flip_protnone_guard() helper, which is a nop on 2-level paging but inverts the address bits in all other paging modes. This doesn't matter for the Xen aspect of the original change. Linux no longer supports running 32bit PV under Xen, and Xen doesn't support running any 32bit PV guests without using PAE paging. Link: https://lkml.kernel.org/r/20260126211046.2096622-1-andrew.cooper3@citrix.com Fixes: b505f1944535 ("x86/kfence: avoid writing L1TF-vulnerable PTEs") Reported-by: Ryusuke Konishi Closes: https://lore.kernel.org/lkml/CAKFNMokwjw68ubYQM9WkzOuH51wLznHpEOMSqtMoV1Rn9JV_gw@mail.gmail.com/ Signed-off-by: Andrew Cooper Tested-by: Ryusuke Konishi Tested-by: Borislav Petkov (AMD) Cc: Alexander Potapenko Cc: Marco Elver Cc: Dmitry Vyukov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Jann Horn Cc: Signed-off-by: Andrew Morton

ARM: 9468/1: fix memset64() on big-endian

2026-01-31T12:58:27+00:00

On big-endian systems the 32-bit low and high halves need to be swapped for the underlying assembly implementation to work correctly. Fixes: fd1d362600e2 ("ARM: implement memset32 & memset64") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Arnd Bergmann Signed-off-by: Russell King (Oracle)

Merge tag 'riscv-for-linus-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

2026-01-31T00:57:36+00:00

Pull RISC-V fixes from Paul Walmsley: - Correct the RISC-V compat.h COMPAT_UTS_MACHINE architecture name - Avoid printing a false warning message on kernels with the SiFive and MIPS errata compiled in - Address a few warnings generated by sparse in the signal handling code - Fix a comment typo * tag 'riscv-for-linus-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: compat: fix COMPAT_UTS_MACHINE definition errata/sifive: remove unreliable warn_miss_errata riscv: fix minor typo in syscall.h comment riscv: signal: fix some warnings reported by sparse