linux.git/arch, branch v6.6.83

x86/boot: Sanitize boot params before parsing command line

2025-03-13T11:58:40+00:00

commit c00b413a96261faef4ce22329153c6abd4acef25 upstream.

The 5-level paging code parses the command line to look for the 'no5lvl'
string, and does so very early, before sanitize_boot_params() has been
called and has been given the opportunity to wipe bogus data from the
fields in boot_params that are not covered by struct setup_header, and
are therefore supposed to be initialized to zero by the bootloader.

This triggers an early boot crash when using syslinux-efi to boot a
recent kernel built with CONFIG_X86_5LEVEL=y and CONFIG_EFI_STUB=n, as
the 0xff padding that now fills the unused PE/COFF header is copied into
boot_params by the bootloader, and interpreted as the top half of the
command line pointer.

Fix this by sanitizing the boot_params before use. Note that there is no
harm in calling this more than once; subsequent invocations are able to
spot that the boot_params have already been cleaned up.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Linus Torvalds 
Cc:  # v6.1+
Link: https://lore.kernel.org/r/20250306155915.342465-2-ardb+git@google.com
Closes: https://lore.kernel.org/all/202503041549.35913.ulrich.gemkow@ikr.uni-stuttgart.de
[ardb: resolve conflict]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

x86/boot: Rename conflicting 'boot_params' pointer to 'boot_params_ptr'

2025-03-13T11:58:40+00:00

commit d55d5bc5d937743aa8ebb7ca3af25111053b5d8c upstream.

The x86 decompressor is built and linked as a separate executable, but
it shares components with the kernel proper, which are either #include'd
as C files, or linked into the decompresor as a static library (e.g, the
EFI stub)

Both the kernel itself and the decompressor define a global symbol
'boot_params' to refer to the boot_params struct, but in the former
case, it refers to the struct directly, whereas in the decompressor, it
refers to a global pointer variable referring to the struct boot_params
passed by the bootloader or constructed from scratch.

This ambiguity is unfortunate, and makes it impossible to assign this
decompressor variable from the x86 EFI stub, given that declaring it as
extern results in a clash. So rename the decompressor version (whose
scope is limited) to boot_params_ptr.

[ mingo: Renamed 'boot_params_p' to 'boot_params_ptr' for clarity ]

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
[ardb: include references to boot_params in x86-stub.[ch]]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

x86/mm: Don't disable PCID when INVLPG has been fixed by microcode

2025-03-13T11:58:39+00:00

commit f24f669d03f884a6ef95cca84317d0f329e93961 upstream.

Per the "Processor Specification Update" documentations referred by
the intel-microcode-20240312 release note, this microcode release has
fixed the issue for all affected models.

So don't disable PCID if the microcode is new enough.  The precise
minimum microcode revision fixing the issue was provided by Pawan
Intel.

[ dhansen: comment and changelog tweaks ]

Signed-off-by: Xi Ruoyao 
Signed-off-by: Dave Hansen 
Acked-by: Pawan Gupta 
Link: https://lore.kernel.org/all/168436059559.404.13934972543631851306.tip-bot2@tip-bot2/
Link: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20240312
Link: https://cdrdv2.intel.com/v1/dl/getContent/740518 # RPL042, rev. 13
Link: https://cdrdv2.intel.com/v1/dl/getContent/682436 # ADL063, rev. 24
Link: https://lore.kernel.org/all/20240325231300.qrltbzf6twm43ftb@desk/
Link: https://lore.kernel.org/all/20240522020625.69418-1-xry111%40xry111.site
Signed-off-by: Pawan Gupta 
Signed-off-by: Greg Kroah-Hartman

Revert "KVM: PPC: e500: Mark "struct page" dirty in kvmppc_e500_shadow_map()"

2025-03-13T11:58:39+00:00

This reverts commit 15d60c13b704f770ba45c58477380d4577cebfa3 which is
commit c9be85dabb376299504e0d391d15662c0edf8273 upstream.

It should not have been applied.

Link: https://lore.kernel.org/r/CABgObfb5U9zwTQBPkPB=mKu-vMrRspPCm4wfxoQpB+SyAnb5WQ@mail.gmail.com
Reported-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

Revert "KVM: PPC: e500: Mark "struct page" pfn accessed before dropping mmu_lock"

2025-03-13T11:58:39+00:00

This reverts commit 59e21c4613b0a46f46eb124984928df46d88ad57 which is
commit 84cf78dcd9d65c45ab73998d4ad50f433d53fb93 upstream.

It should not have been applied.

Link: https://lore.kernel.org/r/CABgObfb5U9zwTQBPkPB=mKu-vMrRspPCm4wfxoQpB+SyAnb5WQ@mail.gmail.com
Reported-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

Revert "KVM: PPC: e500: Use __kvm_faultin_pfn() to handle page faults"

2025-03-13T11:58:39+00:00

This reverts commit ba3cf83f4a5063edb6ee150633e641954ce30478 which is
commit 419cfb983ca93e75e905794521afefcfa07988bb upstream.

It should not have been applied.

Link: https://lore.kernel.org/r/CABgObfb5U9zwTQBPkPB=mKu-vMrRspPCm4wfxoQpB+SyAnb5WQ@mail.gmail.com
Reported-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

Revert "KVM: e500: always restore irqs"

2025-03-13T11:58:39+00:00

This reverts commit b9d93eda1214985d1b3d00a0f9d4306282a5b189 which is
commit 87ecfdbc699cc95fac73291b52650283ddcf929d upstream.

It should not have been applied.

Link: https://lore.kernel.org/r/CABgObfb5U9zwTQBPkPB=mKu-vMrRspPCm4wfxoQpB+SyAnb5WQ@mail.gmail.com
Reported-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

riscv: Fix enabling cbo.zero when running in M-mode

2025-03-13T11:58:38+00:00

commit 3fb3f7164edc467450e650dca51dbe4823315a56 upstream.

When the kernel is running in M-mode, the CBZE bit must be set in the
menvcfg CSR, not in senvcfg.

Cc: 
Fixes: 43c16d51a19b ("RISC-V: Enable cbo.zero in usermode")
Reviewed-by: Andrew Jones 
Signed-off-by: Samuel Holland 
Reviewed-by: Conor Dooley 
Link: https://lore.kernel.org/r/20240228065559.3434837-2-samuel.holland@sifive.com
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Greg Kroah-Hartman

arm64: hugetlb: Fix huge_ptep_get_and_clear() for non-present ptes

2025-03-13T11:58:38+00:00

commit 49c87f7677746f3c5bd16c81b23700bb6b88bfd4 upstream.

arm64 supports multiple huge_pte sizes. Some of the sizes are covered by
a single pte entry at a particular level (PMD_SIZE, PUD_SIZE), and some
are covered by multiple ptes at a particular level (CONT_PTE_SIZE,
CONT_PMD_SIZE). So the function has to figure out the size from the
huge_pte pointer. This was previously done by walking the pgtable to
determine the level and by using the PTE_CONT bit to determine the
number of ptes at the level.

But the PTE_CONT bit is only valid when the pte is present. For
non-present pte values (e.g. markers, migration entries), the previous
implementation was therefore erroneously determining the size. There is
at least one known caller in core-mm, move_huge_pte(), which may call
huge_ptep_get_and_clear() for a non-present pte. So we must be robust to
this case. Additionally the "regular" ptep_get_and_clear() is robust to
being called for non-present ptes so it makes sense to follow the
behavior.

Fix this by using the new sz parameter which is now provided to the
function. Additionally when clearing each pte in a contig range, don't
gather the access and dirty bits if the pte is not present.

An alternative approach that would not require API changes would be to
store the PTE_CONT bit in a spare bit in the swap entry pte for the
non-present case. But it felt cleaner to follow other APIs' lead and
just pass in the size.

As an aside, PTE_CONT is bit 52, which corresponds to bit 40 in the swap
entry offset field (layout of non-present pte). Since hugetlb is never
swapped to disk, this field will only be populated for markers, which
always set this bit to 0 and hwpoison swap entries, which set the offset
field to a PFN; So it would only ever be 1 for a 52-bit PVA system where
memory in that high half was poisoned (I think!). So in practice, this
bit would almost always be zero for non-present ptes and we would only
clear the first entry if it was actually a contiguous block. That's
probably a less severe symptom than if it was always interpreted as 1
and cleared out potentially-present neighboring PTEs.

Cc: stable@vger.kernel.org
Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
Reviewed-by: Catalin Marinas 
Signed-off-by: Ryan Roberts 
Link: https://lore.kernel.org/r/20250226120656.2400136-3-ryan.roberts@arm.com
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

mm: hugetlb: Add huge page size param to huge_ptep_get_and_clear()

2025-03-13T11:58:38+00:00

commit 02410ac72ac3707936c07ede66e94360d0d65319 upstream.

In order to fix a bug, arm64 needs to be told the size of the huge page
for which the huge_pte is being cleared in huge_ptep_get_and_clear().
Provide for this by adding an `unsigned long sz` parameter to the
function. This follows the same pattern as huge_pte_clear() and
set_huge_pte_at().

This commit makes the required interface modifications to the core mm as
well as all arches that implement this function (arm64, loongarch, mips,
parisc, powerpc, riscv, s390, sparc). The actual arm64 bug will be fixed
in a separate commit.

Cc: stable@vger.kernel.org
Fixes: 66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
Acked-by: David Hildenbrand 
Reviewed-by: Alexandre Ghiti  # riscv
Reviewed-by: Christophe Leroy 
Reviewed-by: Catalin Marinas 
Reviewed-by: Anshuman Khandual 
Signed-off-by: Ryan Roberts 
Acked-by: Alexander Gordeev  # s390
Link: https://lore.kernel.org/r/20250226120656.2400136-2-ryan.roberts@arm.com
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman