Re: [PATCHv3 04/12] uprobes/x86: Move optimized uprobe from nop5 to nop10

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, May 22, 2026 at 11:50:44AM -0700, Andrii Nakryiko wrote:
> On Thu, May 21, 2026 at 5:44 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Andrii reported an issue with optimized uprobes [1] that can clobber
> > redzone area with call instruction storing return address on stack
> > where user code may keep temporary data without adjusting rsp.
> >
> > Fixing this by moving the optimized uprobes on top of 10-bytes nop
> > instruction, so we can squeeze another instruction to escape the
> > redzone area before doing the call, like:
> >
> >   lea -0x80(%rsp), %rsp
> >   call tramp
> >
> > Note the lea instruction is used to adjust the rsp register without
> > changing the flags.
> >
> > We use nop10 and following transofrmation to optimized instructions
> > above and back as suggested by Peterz [2].
> >
> > Optimize path (int3_update_optimize):
> >
> >   1) Initial state after set_swbp() installed the uprobe:
> >       cc 2e 0f 1f 84 00 00 00 00 00
> >
> >      From offset 0 this is INT3 followed by the tail of the original
> >      10-byte NOP.
> >
> >   2) Trap the call slot before rewriting the NOP tail:
> >       cc 2e 0f 1f 84 [cc] 00 00 00 00
> >
> >      From offset 0 this traps on the uprobe INT3.  A thread reaching
> >      offset 5 traps on the temporary INT3 instead of seeing a partially
> >      patched call.
> >
> >   3) Rewrite the LEA tail and call displacement, keeping both INT3 bytes:
> >       cc [8d 64 24 80] cc [d0 d1 d2 d3]
> >
> >      From offset 0 and offset 5 this still traps.  The bytes between
> >      them are not executable entry points while both traps are in place.
> >
> >   4) Restore the call opcode at offset 5:
> >       cc 8d 64 24 80 [e8] d0 d1 d2 d3
> >
> >      From offset 0 this still traps.  From offset 5 the instruction is
> >      the final CALL to the uprobe trampoline.
> >
> 
> I'm sorry if I'm slow, but I don't understand why we need that second
> cc at offset 5? Isn't original nop10 processed by CPU as single
> instruction? So it will either be at ip of nop10, or at ip+10, no? If
> we trap at ip and in int3 handler +10 from there while we are
> installing lea+call, why do we need cc on byte 5?
> 
> I.e., I don't understand how CPU can end up being at ip+5 until we
> finalize lea+call sequence? Can it?

hum, so I though it's for the case when you do unoptimize+optimize,
then you can have cpu executing the previous lea and hitting the int3
on +5 offset.. but as pointed by Peter (and you) the call instruction
never changes, so now I'm not sure why we need it

jirka