linux-kernel - Re: [PATCH bpf-next v7 07/11] bpf,x86: add fsession support for x86

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: <598aec184ed820be7f244c2c14b1c0b75442e7567eb52abb15dd6875053c4958@mail.kernel.org>
Date: Wed,  7 Jan 2026 07:11:16 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: menglong8.dong@...il.com,ast@...nel.org,andrii@...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 v7 07/11] bpf,x86: add fsession support for x86_64

> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index a87304161d45..32c13175bc65 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -3094,12 +3094,17 @@ static int emit_cond_near_jump(u8 **pprog, void *func, void *ip, u8 jmp_cond)
>  static int invoke_bpf(const struct btf_func_model *m, u8 **pprog,
>  		      struct bpf_tramp_links *tl, int stack_size,
>  		      int run_ctx_off, bool save_ret,
> -		      void *image, void *rw_image)
> +		      void *image, void *rw_image, u64 func_meta)
>  {
>  	int i;
>  	u8 *prog = *pprog;
>
>  	for (i = 0; i < tl->nr_links; i++) {
> +		if (tl->links[i]->link.prog->call_session_cookie) {
> +			/* 'stack_size + 8' is the offset of func_md in stack */
> +			emit_st_r0_imm64(&prog, func_meta, stack_size + 8);
> +			func_meta -= (1 << BPF_TRAMP_M_COOKIE);
> +		}

This decrement of func_meta is problematic for fsession programs. When
invoke_bpf() is called for fentry, func_meta gets decremented for each
program with call_session_cookie. Later, when invoke_bpf() is called
for fexit, it receives this already-decremented func_meta value.

Since fsession programs appear in both fentry and fexit lists (same
program object), call_session_cookie is true for both. The fexit part
will see a different cookie offset than the fentry part saw.

For example, with one fsession program:
  - fentry stores func_meta with cookie offset N, then decrements to N-1
  - fexit receives N-1, stores it, and the BPF program reads offset N-1

Should the func_meta offset be reset for fexit so that each fsession
program's fentry and fexit parts access the same cookie slot?

[ ... ]

> @@ -3383,9 +3395,19 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
>  		}
>  	}
>
> +	if (bpf_fsession_cnt(tlinks)) {
> +		/* clear all the session cookies' value */
> +		for (int i = 0; i < cookie_cnt; i++)
> +			emit_st_r0_imm64(&prog, 0, cookie_off - 8 * i);
> +		/* clear the return value to make sure fentry always get 0 */
> +		emit_st_r0_imm64(&prog, 0, 8);
> +	}
> +	func_meta = nr_regs + (((cookie_off - regs_off) / 8) << BPF_TRAMP_M_COOKIE);
> +
>  	if (fentry->nr_links) {
>  		if (invoke_bpf(m, &prog, fentry, regs_off, run_ctx_off,
> -			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image))
> +			       flags & BPF_TRAMP_F_RET_FENTRY_RET, image, rw_image,
> +			       func_meta))
>  			return -EINVAL;
>  	}

[ ... ]

> @@ -3445,9 +3467,14 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
>  		}
>  	}
>
> +	/* set the "is_return" flag for fsession */
> +	func_meta += (1 << BPF_TRAMP_M_IS_RETURN);
> +	if (bpf_fsession_cnt(tlinks))
> +		emit_st_r0_imm64(&prog, func_meta, nregs_off);
> +
>  	if (fexit->nr_links) {
>  		if (invoke_bpf(m, &prog, fexit, regs_off, run_ctx_off,
> -			       false, image, rw_image)) {
> +			       false, image, rw_image, func_meta)) {

At this point func_meta has already been decremented during the fentry
invoke_bpf() call above. When invoke_bpf() processes the fexit list and
encounters an fsession program (which has call_session_cookie set since
it is the same program object), it will store this modified func_meta.

The cookie offset encoded in func_meta will be different from what the
fentry part stored, causing bpf_session_cookie() to return a pointer to
a different memory location for fexit than for fentry.

> +			ret = -EINVAL;
> +			goto cleanup;
> +		}


---
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/20773233136