netdev - Re: [PATCH bpf-next v11 04/12] bpf: support fsession for bpf_session_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5071572.31r3eYUQgx@7940hx>
Date: Fri, 23 Jan 2026 16:15:50 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: menglong8.dong@...il.com, andrii@...nel.org, bot+bpf-ci@...nel.org
Cc: daniel@...earbox.net, martin.lau@...ux.dev, eddyz87@...il.com,
 song@...nel.org, yonghong.song@...ux.dev, john.fastabend@...il.com,
 kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
 davem@...emloft.net, dsahern@...nel.org, tglx@...utronix.de,
 mingo@...hat.com, jiang.biao@...ux.dev, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 bpf@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 ast@...nel.org, andrii@...nel.org, daniel@...earbox.net,
 martin.lau@...nel.org, eddyz87@...il.com, yonghong.song@...ux.dev,
 clm@...a.com, ihor.solodrai@...ux.dev
Subject:
 Re: [PATCH bpf-next v11 04/12] bpf: support fsession for
 bpf_session_is_return

On 2026/1/23 16:07 bot+bpf-ci@...nel.org write:
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 41228b0add52..29eecd79352e 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1229,6 +1229,8 @@ enum {
> >  #endif
> >  };
> >
> > +#define BPF_TRAMP_IS_RETURN_SHIFT	63
> > +
> >  struct bpf_tramp_links {
> 
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 19fd16697262..2ae8f29b854f 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -23011,6 +23011,19 @@ static int fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> >  		   desc->func_id == special_kfunc_list[KF_bpf_rdonly_cast]) {
> >  		insn_buf[0] = BPF_MOV64_REG(BPF_REG_0, BPF_REG_1);
> >  		*cnt = 1;
> > +	} else if (desc->func_id == special_kfunc_list[KF_bpf_session_is_return] &&
> > +		   env->prog->expected_attach_type == BPF_TRACE_FSESSION) {
> > +		/*
> > +		 * inline the bpf_session_is_return() for fsession:
> > +		 *   bool bpf_session_is_return(void *ctx)
> > +		 *   {
> > +		 *       return (((u64 *)ctx)[-1] >> BPF_TRAMP_IS_RETURN_SHIFT) & 1;
> > +		 *   }
> > +		 */
> > +		insn_buf[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8);
> > +		insn_buf[1] = BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, BPF_TRAMP_IS_RETURN_SHIFT);
> > +		insn_buf[2] = BPF_ALU64_IMM(BPF_AND, BPF_REG_0, 1);
> > +		*cnt = 3;
> > +	}
> 
> The inline implementation reads bit 63 of ctx[-1] to check the is_return
> flag. However, looking at the x86 trampoline code in
> arch/x86/net/bpf_jit_comp.c, the trampoline only stores nr_regs in ctx[-1]:
> 
>     emit_mov_imm64(&prog, BPF_REG_0, 0, (u32) nr_regs);
>     emit_stx(&prog, BPF_DW, BPF_REG_FP, BPF_REG_0, -nregs_off);
> 
> The is_return flag (bit 63) is never set by the current trampoline code.
> This means bpf_session_is_return() will always return 0 for fsession
> programs, even when executing at the return point.
> 
> I see this is fixed later in the series by commit ba766b26e776 ("bpf,x86:
> add fsession support for x86_64") which adds:
> 
>     func_meta |= (1ULL << BPF_TRAMP_IS_RETURN_SHIFT);
>     if (bpf_fsession_cnt(tlinks))
>         emit_store_stack_imm64(&prog, BPF_REG_0, -func_meta_off, func_meta);
> 
> Should this commit be squashed with the x86 trampoline changes to ensure
> the feature works correctly at each point in the series?

As I said before, this patch implement the common part of the fsession.
and we implement the architecture specific code for x86_64 in the later
patch.

> 
> [ ... ]
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21278745581
>