linux-stable.git/arch/arm64/kernel, branch linux-6.17.y

arm64: Reject modules with internal alternative callbacks

2025-12-12T17:40:20+00:00

[ Upstream commit 8e8ae788964aa2573b4335026db4068540fa6a86 ]

During module loading, check if a callback function used by the
alternatives specified in the '.altinstruction' ELF section (if present)
is located in core kernel .text. If not fail module loading before
callback is called.

Reported-by: Fanqin Cui 
Closes: https://lore.kernel.org/all/20250807072700.348514-1-fanqincui@163.com/
Signed-off-by: Adrian Barnaś 
Reviewed-by: Ard Biesheuvel 
[will: Folded in 'noinstr' tweak from Mark]
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

Revert "ACPI: Suppress misleading SPCR console message when SPCR table is absent"

2025-12-06T21:27:40+00:00

commit eeb8c19896952e18fb538ec76e603884070a6c6a upstream.

This reverts commit bad3fa2fb9206f4dcec6ddef094ec2fbf6e8dcb2.

Commit bad3fa2fb920 ("ACPI: Suppress misleading SPCR console message
when SPCR table is absent") mistakenly assumes acpi_parse_spcr()
returning 0 to indicate a failure to parse SPCR. While addressing the
resultant incorrect logging it was deemed that dropping the message is
a better approach as it is not particularly useful.

Roll back the commit introducing the bug as a step towards dropping
the log message.

Link: https://lore.kernel.org/all/aQN0YWUYaPYWpgJM@willie-the-truck/
Signed-off-by: Punit Agrawal 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: kprobes: check the return value of set_memory_rox()

2025-11-24T09:37:23+00:00

[ Upstream commit 0ec364c0c95fc85bcbc88f1a9a06ebe83c88e18c ]

Since commit a166563e7ec3 ("arm64: mm: support large block mapping when
rodata=full"), __change_memory_common has more chance to fail due to
memory allocation failure when splitting page table. So check the return
value of set_memory_rox(), then bail out if it fails otherwise we may have
RW memory mapping for kprobes insn page.

Fixes: 195a1b7d8388 ("arm64: kprobes: call set_memory_rox() for kprobe page")
Reviewed-by: Ryan Roberts 
Reviewed-by: Dev Jain 
Signed-off-by: Yang Shi 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c

2025-11-02T13:18:04+00:00

[ Upstream commit 35561bab768977c9e05f1f1a9bc00134c85f3e28 ]

The include/generated/asm-offsets.h is generated in Kbuild during
compiling from arch/SRCARCH/kernel/asm-offsets.c. When we want to
generate another similar offset header file, circular dependency can
happen.

For example, we want to generate a offset file include/generated/test.h,
which is included in include/sched/sched.h. If we generate asm-offsets.h
first, it will fail, as include/sched/sched.h is included in asm-offsets.c
and include/generated/test.h doesn't exist; If we generate test.h first,
it can't success neither, as include/generated/asm-offsets.h is included
by it.

In x86_64, the macro COMPILE_OFFSETS is used to avoid such circular
dependency. We can generate asm-offsets.h first, and if the
COMPILE_OFFSETS is defined, we don't include the "generated/test.h".

And we define the macro COMPILE_OFFSETS for all the asm-offsets.c for this
purpose.

Signed-off-by: Menglong Dong 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Sasha Levin

arm64: errata: Apply workarounds for Neoverse-V3AE

2025-10-23T14:24:38+00:00

commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream.

Neoverse-V3AE is also affected by erratum #3312417, as described in its
Software Developer Errata Notice (SDEN) document:

  Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417
  https://developer.arm.com/documentation/SDEN-2615521/9-0/

Enable the workaround for Neoverse-V3AE, and document this.

Signed-off-by: Mark Rutland 
Cc: James Morse 
Cc: Will Deacon 
Cc: Catalin Marinas 
Signed-off-by: Ryan Roberts 
Signed-off-by: Will Deacon 
Signed-off-by: Ryan Roberts 
Signed-off-by: Greg Kroah-Hartman

arm64: debug: always unmask interrupts in el0_softstp()

2025-10-23T14:24:38+00:00

commit ea0d55ae4b3207c33691a73da3443b1fd379f1d2 upstream.

We intend that EL0 exception handlers unmask all DAIF exceptions
before calling exit_to_user_mode().

When completing single-step of a suspended breakpoint, we do not call
local_daif_restore(DAIF_PROCCTX) before calling exit_to_user_mode(),
leaving all DAIF exceptions masked.

When pseudo-NMIs are not in use this is benign.

When pseudo-NMIs are in use, this is unsound. At this point interrupts
are masked by both DAIF.IF and PMR_EL1, and subsequent irq flag
manipulation may not work correctly. For example, a subsequent
local_irq_enable() within exit_to_user_mode_loop() will only unmask
interrupts via PMR_EL1 (leaving those masked via DAIF.IF), and
anything depending on interrupts being unmasked (e.g. delivery of
signals) will not work correctly.

This was detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING.

Move the call to `try_step_suspended_breakpoints()` outside of the check
so that interrupts can be unmasked even if we don't call the step handler.

Fixes: 0ac7584c08ce ("arm64: debug: split single stepping exception entry")
Cc:  # 6.17
Signed-off-by: Ada Couprie Diaz 
Acked-by: Mark Rutland 
[catalin.marinas@arm.com: added Mark's rewritten commit log and some whitespace]
Signed-off-by: Catalin Marinas 
[ada.coupriediaz@arm.com: Fix conflict for v6.17 stable]
Signed-off-by: Ada Couprie Diaz 
Signed-off-by: Greg Kroah-Hartman

arm64: mte: Do not flag the zero page as PG_mte_tagged

2025-10-19T14:37:17+00:00

commit f620d66af3165838bfa845dcf9f5f9b4089bf508 upstream.

Commit 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the
zero page") attempted to fix ptrace() reading of tags from the zero page
by marking it as PG_mte_tagged during cpu_enable_mte(). The same commit
also changed the ptrace() tag access permission check to the VM_MTE vma
flag while turning the page flag test into a WARN_ON_ONCE().

Attempting to set the PG_mte_tagged flag early with
CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled may either hang (after commit
d77e59a8fccd "arm64: mte: Lock a page for MTE tag initialisation") or
have the flags cleared later during page_alloc_init_late(). In addition,
pages_identical() -> memcmp_pages() will reject any comparison with the
zero page as it is marked as tagged.

Partially revert the above commit to avoid setting PG_mte_tagged on the
zero page. Update the __access_remote_tags() warning on untagged pages
to ignore the zero page since it is known to have the tags initialised.

Note that all user mapping of the zero page are marked as pte_special().
The arm64 set_pte_at() will not call mte_sync_tags() on such pages, so
PG_mte_tagged will remain cleared.

Signed-off-by: Catalin Marinas 
Fixes: 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page")
Reported-by: Gergely Kovacs 
Cc: stable@vger.kernel.org # 5.10.x
Cc: Will Deacon 
Cc: David Hildenbrand 
Cc: Lance Yang 
Acked-by: Lance Yang 
Reviewed-by: David Hildenbrand 
Tested-by: Lance Yang 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: kprobes: call set_memory_rox() for kprobe page

2025-10-19T14:37:17+00:00

commit 195a1b7d8388c0ec2969a39324feb8bebf9bb907 upstream.

The kprobe page is allocated by execmem allocator with ROX permission.
It needs to call set_memory_rox() to set proper permission for the
direct map too. It was missed.

Fixes: 10d5e97c1bf8 ("arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page")
Cc: 
Signed-off-by: Yang Shi 
Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: map [_text, _stext) virtual address range non-executable+read-only

2025-10-19T14:36:59+00:00

commit 5973a62efa34c80c9a4e5eac1fca6f6209b902af upstream.

Since the referenced fixes commit, the kernel's .text section is only
mapped starting from _stext; the region [_text, _stext) is omitted. As a
result, other vmalloc/vmap allocations may use the virtual addresses
nominally in the range [_text, _stext). This address reuse confuses
multiple things:

1. crash_prepare_elf64_headers() sets up a segment in /proc/vmcore
   mapping the entire range [_text, _end) to
   [__pa_symbol(_text), __pa_symbol(_end)). Reading an address in
   [_text, _stext) from /proc/vmcore therefore gives the incorrect
   result.
2. Tools doing symbolization (either by reading /proc/kallsyms or based
   on the vmlinux ELF file) will incorrectly identify vmalloc/vmap
   allocations in [_text, _stext) as kernel symbols.

In practice, both of these issues affect the drgn debugger.
Specifically, there were cases where the vmap IRQ stacks for some CPUs
were allocated in [_text, _stext). As a result, drgn could not get the
stack trace for a crash in an IRQ handler because the core dump
contained invalid data for the IRQ stack address. The stack addresses
were also symbolized as being in the _text symbol.

Fix this by bringing back the mapping of [_text, _stext), but now make
it non-executable and read-only. This prevents other allocations from
using it while still achieving the original goal of not mapping
unpredictable data as executable. Other than the changed protection,
this is effectively a revert of the fixes commit.

Fixes: e2a073dde921 ("arm64: omit [_text, _stext) from permanent kernel mapping")
Cc: stable@vger.kernel.org
Signed-off-by: Omar Sandoval 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arch: copy_thread: pass clone_flags as u64

2025-10-15T10:03:13+00:00

[ Upstream commit bbc46b23af5bb934cd1cf066ef4342cee457a24e ]

With the introduction of clone3 in commit 7f192e3cd316 ("fork: add
clone3") the effective bit width of clone_flags on all architectures was
increased from 32-bit to 64-bit, with a new type of u64 for the flags.
However, for most consumers of clone_flags the interface was not
changed from the previous type of unsigned long.

While this works fine as long as none of the new 64-bit flag bits
(CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP) are evaluated, this is still
undesirable in terms of the principle of least surprise.

Thus, this commit fixes all relevant interfaces of the copy_thread
function that is called from copy_process to consistently pass
clone_flags as u64, so that no truncation to 32-bit integers occurs on
32-bit architectures.

Signed-off-by: Simon Schuster 
Link: https://lore.kernel.org/20250901-nios2-implement-clone3-v2-3-53fcf5577d57@siemens-energy.com
Fixes: c5febea0956fd387 ("fork: Pass struct kernel_clone_args into copy_thread")
Acked-by: Guo Ren (Alibaba Damo Academy) 
Acked-by: Andreas Larsson  # sparc
Acked-by: David Hildenbrand 
Acked-by: Geert Uytterhoeven  # m68k
Reviewed-by: Arnd Bergmann 
Signed-off-by: Christian Brauner 
Signed-off-by: Sasha Levin