Re: [PATCH 2/3] arm64: patching: Fix instruction byte order in aarch64_insn_set()

[David Laight <david.laight.linux@gmail.com>]

On Wed, 11 Nov 2026 14:52:44 +0800
"Rui Qi" <qirui.001@bytedance.com> wrote:

> On 10/16/26 12:57 AM, Catalin Marinas wrote:
> > On Sat, Oct 10, 2026 at 04:50:54PM +0800, Rui Qi wrote:  
> >> aarch64_insn_set() passes the host-endian u32 instruction straight to
> >> text_poke_memset(), which memset32()'s it into memory in host byte order.
> >> AArch64 instructions must be little-endian in memory, so on a big-endian
> >> kernel the written bytes are reversed and the CPU takes an UNDEFINED
> >> instruction exception when fetching them.  The sibling aarch64_insn_write()
> >> already converts with cpu_to_le32(); aarch64_insn_set() does not.
> >>
> >> This is reachable in-tree: bpf_arch_text_invalidate() fills freed JIT
> >> regions with AARCH64_BREAK_FAULT through aarch64_insn_set(), and arm64
> >> selects HAVE_EBPF_JIT without a big-endian guard, so the path is taken on
> >> BE kernels with BPF JIT.  The direct-fill loop in the same file already
> >> cpu_to_le32()'s the constant, confirming the expected byte order.
> >>
> >> Convert the instruction to little-endian before the memset, mirroring
> >> aarch64_insn_write().  On LE the conversion is a no-op, so behaviour is
> >> unchanged.  
> > 
> > We are just about to remove big-endian support (in 7.4).
> >   
> 
> Understood.  In -next arm64 no longer has a config CPU_BIG_ENDIAN and
> nothing selects it, so 1/3 and 2/3 are fixing a configuration that no
> longer exists.  I'll drop both.

Should it still be fixed in the LTS kernels?
(or disable BPF JIT for arm BE)

David

> 
> 3/3 ("arm64: module: Use text-poke for late PLT/veneer emission") is
> independent of the byte-order work: it routes
> module_emit_plt_entry() / module_emit_veneer_for_adrp() through
> aarch64_insn_copy() so a late livepatch relocation that falls back to
> PLT emission does not write into the ROX .plt and Data Abort.  That
> path is reachable on LE today (klp_write_section_relocs() on a
> MODULE_STATE_LIVE patch module), so it is not BE-specific; it carries
> Fixes: 91b89a634487 and Cc: stable.
> 
> I'll resend 3/3 as a standalone patch in a new thread.  Happy to route
> it a particular way if you'd prefer.
>