From: sashiko-bot@kernel.org
To: "Pawan Gupta" <pawan.kumar.gupta@linux.intel.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 7.1.y 3/6] bpf: Restrict JIT predictor flush to cBPF
Date: Thu, 09 Jul 2026 22:35:37 +0000 [thread overview]
Message-ID: <20260709223537.D189A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260709-cbpf-jit-spray-hardening-7-1-y-v1-3-5ac5a2d6797f@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Restricting JIT predictor flush to cBPF bypasses Spectre v2 mitigations for unprivileged native eBPF programs.
--
--- Patch [3]: [PATCH 7.1.y 3/6] bpf: Restrict JIT predictor flush to cBPF ---
commit 96d12fd545f6cf1b750e18b7bd03c2fd3abf27be
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
bpf: Restrict JIT predictor flush to cBPF
This commit restricts the branch predictor flush on BPF JIT memory reuse to
only execute for cBPF programs. The rationale provided is that only cBPF
programs can be loaded by an unprivileged user, whereas eBPF is privileged
by default.
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index f49b9b23f95e6..1b7e74e63bd4b 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
[ ... ]
> @@ -957,7 +957,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
> * safe because cBPF programs (the unprivileged attack surface)
> * are bounded well below a pack size.
> */
> - if (static_branch_unlikely(&bpf_pred_flush_enabled))
> + if (was_classic && static_branch_unlikely(&bpf_pred_flush_enabled))
> pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");
> size = round_up(size, PAGE_SIZE);
> ptr = bpf_jit_alloc_exec(size);
[Severity: High]
Does this bypass the Spectre v2 mitigations for unprivileged native eBPF
programs?
If kernel.unprivileged_bpf_disabled=0 (which is the default when
CONFIG_BPF_UNPRIV_DEFAULT_OFF is not set), unprivileged users can load native
eBPF programs such as BPF_PROG_TYPE_SOCKET_FILTER. Since these are not cBPF,
was_classic is false, and the warning logic for large allocations explicitly
bypasses the check in bpf_prog_pack_alloc().
[ ... ]
> @@ -989,7 +989,9 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
> pos = 0;
>
> found_free_area:
> - static_call_cond(bpf_arch_pred_flush)();
> + /* Flush only for cBPF as it may contain a crafted gadget */
> + if (static_branch_unlikely(&bpf_pred_flush_enabled) && was_classic)
> + static_call_cond(bpf_arch_pred_flush)();
> bitmap_set(pack->bitmap, pos, nbits);
> ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
[Severity: High]
For unprivileged native eBPF programs, the predictor flush during memory pack
reuse is also skipped here. Could this allow an unprivileged attacker to load
a crafted JIT gadget into a reused memory chunk and exploit leftover branch
predictor state from previously executed privileged BPF programs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-cbpf-jit-spray-hardening-7-1-y-v1-0-5ac5a2d6797f@linux.intel.com?part=3
next prev parent reply other threads:[~2026-07-09 22:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 22:22 [PATCH 7.1.y 0/6] cBPF JIT spray hardening Pawan Gupta
2026-07-09 22:23 ` [PATCH 7.1.y 1/6] bpf: Support for hardening against JIT spraying Pawan Gupta
2026-07-09 22:37 ` sashiko-bot
2026-07-09 22:52 ` bot+bpf-ci
2026-07-09 22:23 ` [PATCH 7.1.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation Pawan Gupta
2026-07-09 22:37 ` sashiko-bot
2026-07-09 22:23 ` [PATCH 7.1.y 3/6] bpf: Restrict JIT predictor flush to cBPF Pawan Gupta
2026-07-09 22:35 ` sashiko-bot [this message]
2026-07-09 22:23 ` [PATCH 7.1.y 4/6] bpf: Skip redundant IBPB in pack allocator Pawan Gupta
2026-07-09 22:24 ` [PATCH 7.1.y 5/6] bpf: Prefer packs that won't trigger an IBPB flush on allocation Pawan Gupta
2026-07-09 22:24 ` [PATCH 7.1.y 6/6] bpf: Prefer dirty packs for eBPF allocations Pawan Gupta
2026-07-10 21:03 ` [PATCH 7.1.y 0/6] cBPF JIT spray hardening Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260709223537.D189A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox