[BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Jérémy Jean]

Hello,

With the help of AI models, I found a bug in the x86 timed may_goto path that
leads to a verifier/JIT state mismatch on private-stack programs.

The root cause is that timed may_goto fixups pass a stack offset in BPF_REG_AX
and the x86 trampoline reconstructs the counter pointer from native %rbp. That
is incorrect once private-stack JIT mode is enabled: ordinary BPF frame pointer
accesses are remapped from %rbp to %r9, but arch_bpf_timed_may_goto() still
uses %rbp and ends up reading and writing the native JIT frame instead of the
private BPF stack.

The bug was introduced by 2fb761823ead ("bpf, x86: Add x86 JIT support for timed
may_goto"). I reproduced it on a KASAN-enabled x86_64 kernel based on v7.2,
however KASAN does not trigger because the bad write stays inside the native
JIT frame. Yet, the saved-register corruption is observable.

I have not included a patch here because the fix seems subtle to me and would
likely touch many files for different arch.

I can share the minimal reproducer and other details privately with maintainers
if useful.

Best regards,
Jérémy

Fixes: 2fb761823ead ("bpf, x86: Add x86 JIT support for timed may_goto")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

Re: [BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Alexei Starovoitov]

On Mon Aug 24, 2026 at 2:31 PM PDT, Jérémy Jean wrote:
> Hello,
>
> With the help of AI models, I found a bug in the x86 timed may_goto path that
> leads to a verifier/JIT state mismatch on private-stack programs.
>
> The root cause is that timed may_goto fixups pass a stack offset in BPF_REG_AX
> and the x86 trampoline reconstructs the counter pointer from native %rbp. That
> is incorrect once private-stack JIT mode is enabled: ordinary BPF frame pointer
> accesses are remapped from %rbp to %r9, but arch_bpf_timed_may_goto() still
> uses %rbp and ends up reading and writing the native JIT frame instead of the
> private BPF stack.
>
> The bug was introduced by 2fb761823ead ("bpf, x86: Add x86 JIT support for timed
> may_goto"). I reproduced it on a KASAN-enabled x86_64 kernel based on v7.2,
> however KASAN does not trigger because the bad write stays inside the native
> JIT frame. Yet, the saved-register corruption is observable.
>
> I have not included a patch here because the fix seems subtle to me and would
> likely touch many files for different arch.
>
> I can share the minimal reproducer and other details privately with maintainers
> if useful.

Just send a fix and a selftest to the list.

Re: [BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Siddharth Chintamaneni]

On Tue, 25 Aug 2026 at 18:10, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Mon Aug 24, 2026 at 2:31 PM PDT, Jérémy Jean wrote:
> > Hello,
> >
> > With the help of AI models, I found a bug in the x86 timed may_goto path that
> > leads to a verifier/JIT state mismatch on private-stack programs.
> >
> > The root cause is that timed may_goto fixups pass a stack offset in BPF_REG_AX
> > and the x86 trampoline reconstructs the counter pointer from native %rbp. That
> > is incorrect once private-stack JIT mode is enabled: ordinary BPF frame pointer
> > accesses are remapped from %rbp to %r9, but arch_bpf_timed_may_goto() still
> > uses %rbp and ends up reading and writing the native JIT frame instead of the
> > private BPF stack.
> >
> > The bug was introduced by 2fb761823ead ("bpf, x86: Add x86 JIT support for timed
> > may_goto"). I reproduced it on a KASAN-enabled x86_64 kernel based on v7.2,
> > however KASAN does not trigger because the bad write stays inside the native
> > JIT frame. Yet, the saved-register corruption is observable.
> >
> > I have not included a patch here because the fix seems subtle to me and would
> > likely touch many files for different arch.
> >
> > I can share the minimal reproducer and other details privately with maintainers
> > if useful.
>
> Just send a fix and a selftest to the list.
>

Jeremy,

I just wanted to check whether you're working on a patch for this. if
not, I'd be happy to take a look.

Re: [BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Jérémy Jean]

On 2026-09-01 00:57, Siddharth Chintamaneni wrote:
> On Tue, 25 Aug 2026 at 18:10, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> 
>> On Mon Aug 24, 2026 at 2:31 PM PDT, Jérémy Jean wrote:
>> > Hello,
>> >
>> > With the help of AI models, I found a bug in the x86 timed may_goto path that
>> > leads to a verifier/JIT state mismatch on private-stack programs.
>> >
>> > The root cause is that timed may_goto fixups pass a stack offset in BPF_REG_AX
>> > and the x86 trampoline reconstructs the counter pointer from native %rbp. That
>> > is incorrect once private-stack JIT mode is enabled: ordinary BPF frame pointer
>> > accesses are remapped from %rbp to %r9, but arch_bpf_timed_may_goto() still
>> > uses %rbp and ends up reading and writing the native JIT frame instead of the
>> > private BPF stack.
>> >
>> > The bug was introduced by 2fb761823ead ("bpf, x86: Add x86 JIT support for timed
>> > may_goto"). I reproduced it on a KASAN-enabled x86_64 kernel based on v7.2,
>> > however KASAN does not trigger because the bad write stays inside the native
>> > JIT frame. Yet, the saved-register corruption is observable.
>> >
>> > I have not included a patch here because the fix seems subtle to me and would
>> > likely touch many files for different arch.
>> >
>> > I can share the minimal reproducer and other details privately with maintainers
>> > if useful.
>> 
>> Just send a fix and a selftest to the list.
>> 
> 
> Jeremy,
> 
> I just wanted to check whether you're working on a patch for this. if
> not, I'd be happy to take a look.

Hello,

No, not at the moment.
Feel free to ask if I can be of some help

Regards,
Jérémy

Re: [BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Siddharth Chintamaneni]

On Tue, 1 Sept 2026 at 00:11, Jérémy Jean <jeremy.jean@oss.cyber.gouv.fr> wrote:
>
> On 2026-09-01 00:57, Siddharth Chintamaneni wrote:
> > On Tue, 25 Aug 2026 at 18:10, Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> >>
> >> On Mon Aug 24, 2026 at 2:31 PM PDT, Jérémy Jean wrote:
> >> > Hello,
> >> >
> >> > With the help of AI models, I found a bug in the x86 timed may_goto path that
> >> > leads to a verifier/JIT state mismatch on private-stack programs.
> >> >
> >> > The root cause is that timed may_goto fixups pass a stack offset in BPF_REG_AX
> >> > and the x86 trampoline reconstructs the counter pointer from native %rbp. That
> >> > is incorrect once private-stack JIT mode is enabled: ordinary BPF frame pointer
> >> > accesses are remapped from %rbp to %r9, but arch_bpf_timed_may_goto() still
> >> > uses %rbp and ends up reading and writing the native JIT frame instead of the
> >> > private BPF stack.
> >> >
> >> > The bug was introduced by 2fb761823ead ("bpf, x86: Add x86 JIT support for timed
> >> > may_goto"). I reproduced it on a KASAN-enabled x86_64 kernel based on v7.2,
> >> > however KASAN does not trigger because the bad write stays inside the native
> >> > JIT frame. Yet, the saved-register corruption is observable.
> >> >
> >> > I have not included a patch here because the fix seems subtle to me and would
> >> > likely touch many files for different arch.
> >> >
> >> > I can share the minimal reproducer and other details privately with maintainers
> >> > if useful.
> >>
> >> Just send a fix and a selftest to the list.
> >>
> >
> > Jeremy,
> >
> > I just wanted to check whether you're working on a patch for this. if
> > not, I'd be happy to take a look.
>
> Hello,
>
> No, not at the moment.
> Feel free to ask if I can be of some help
>

Let me playaorund with it. I'll let you know if I have more questions. Thanks!

> Regards,
> Jérémy

Re: [BUG] bpf: x86 timed may_goto corrupts private-stack JIT state

[Siddharth Chintamaneni]

On Tue, 1 Sept 2026 at 10:42, Siddharth Chintamaneni
<sidchintamaneni@gmail.com> wrote:
>
<SNIP>
> > > Jeremy,
> > >
> > > I just wanted to check whether you're working on a patch for this. if
> > > not, I'd be happy to take a look.
> >
> > Hello,
> >
> > No, not at the moment.
> > Feel free to ask if I can be of some help
> >
>
> Let me playaorund with it. I'll let you know if I have more questions. Thanks!
>

I have a question for the maintainers - the fix involves changes to
all the arch specific trampolines `arch/*/net/bpf_timed_may_goto.S`.

Is it fine if I include all of them in a single patchset?

<SNIP>