Re: [PATCH] arm64: bpf: Fix UBSAN misaligned access in BPF JIT

[Will Deacon]

On Wed, Feb 25, 2026 at 05:53:18PM +0000, Fuad Tabba wrote:
> On Wed, 25 Feb 2026 at 17:48, Will Deacon <will@xxxxxxxxxx> wrote:
> >
> > On Wed, Feb 25, 2026 at 05:46:52PM +0800, Xu Kuohai wrote:
> > > Interesting, I think the plt target should be 64-bit aligned to ensure
> > > atomic reading on arm64. It can be updated concurrently by WRITE_ONCE
> > > in the bpf_arch_text_poke function while the ldr instruction in the plt is
> > > executed. If it is not aligned correctly, the ldr may read a half-old
> > > half-new value, causing the plt to jump to an invalid destination.
> >
> > Thanks for pointing that out; I hadn't realised that we patched live
> > PLTs!
> >
> > > To avoid over-aligning the entire buffer, how about fixing the padding
> > > method in build_plt to just make the plt target aligned correctly?
> >
> > Makes sense to me.
> 
> As I noted in my reply to Xu, and keeping in mind that this is very
> new to me (so take it with a huge pinch of salt), I don't think this
> is correct, but that my original patch is probably the best fix:

[...]

> > I'm not sure about this. If my reading of the code is correct, during
> > the first JIT pass, ctx->image is NULL. The current padding logic in
> > build_plt() looks like this:
> >
> >         /* make sure target is 64-bit aligned */
> >         if ((ctx->idx + PLT_TARGET_OFFSET / AARCH64_INSN_SIZE) % 2)
> >             emit(A64_NOP, ctx);

Aha, so this handles the case where we have an odd number of instructions
and need to chuck out a NOP to align the PLT target. So, yes, I agree
that aligning the entire region to 8 bytes seems to be the expected
behaviour, otherwise that NOP could actually result in a misaligned
address!

Will