> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index a656a8572bdb..393d9eacd215 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
[ ... ]
> @@ -1583,6 +1583,22 @@ bool bpf_insn_is_indirect_target(const struct
> bpf_verifier_env *env, const struc
> return env->insn_aux_data[insn_idx].indirect_target;
> }
>
> +bool bpf_insn_accesses_stack_only(const struct bpf_verifier_env *env,
> + const struct bpf_prog *prog, int insn_idx)
> +{
> + struct bpf_insn *insn;
> +
> + /* cBPF: we have no verifier state, do a best-effort check based on
> + * dst/src reg
> + */
> + insn_idx += prog->aux->subprog_start;
> + insn = (struct bpf_insn *)prog->insnsi + insn_idx;
> + if (!env)
> + return insn->dst_reg == BPF_REG_FP ||
> + insn->src_reg == BPF_REG_FP;
> + return !env->insn_aux_data[insn_idx].non_stack_access;
> +}
> +
Sashiko bot raised a concern about this code in v2 review: When JIT
compiling an eBPF subprogram, prog points to the subprogram and
prog->insnsi only spans the subprogram's instructions.
By adding prog->aux->subprog_start to insn_idx, doesn't this result in
out-of-bounds pointer arithmetic for insn? Even though the pointer is not
dereferenced here because of the if (!env) check, could this trigger UBSAN
bounds-checking traps?
Should the insn pointer calculation be deferred until inside the !env block
where it is genuinely needed for cBPF?
Reference:
https://lore.kernel.org/bpf/[email protected]/
> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
> index 5aa3f7d99ac9..5228c910fbf5 100644
> --- a/kernel/bpf/fixups.c
> +++ b/kernel/bpf/fixups.c
[ ... ]
> @@ -185,16 +185,22 @@ static void adjust_insn_aux_data(struct
> bpf_verifier_env *env,
> }
>
> /*
> - * The indirect_target flag of the original instruction was moved to
> the last of the
> - * new instructions by the above memmove and memset, but the indirect
> jump target is
> - * actually the first instruction, so move it back. This also matches
> with the behavior
> - * of bpf_insn_array_adjust(), which preserves xlated_off to point to
> the first new
> - * instruction.
> + * The indirect_target and non_stack_access flags of the original
> + * instruction were moved to the last of the new instructions by the
> + * above memmove and memset, but those actually match the first
> + * instruction, so move them back. This also matches with the behavior
> + * of bpf_insn_array_adjust(), which preserves xlated_off to point to
> + * the first new instruction.
> */
> if (data[off + cnt - 1].indirect_target) {
> data[off].indirect_target = 1;
> data[off + cnt - 1].indirect_target = 0;
> }
> +
> + if (data[off + cnt - 1].non_stack_access) {
> + data[off].non_stack_access = 1;
> + data[off + cnt - 1].non_stack_access = 0;
> + }
> }
Sashiko bot raised a concern about this logic in v2 review: When
bpf_patch_insn_data() expands a single instruction into multiple
instructions, this logic restricts the non_stack_access flag to only the
first instruction of the patched sequence and clears it for the rest.
Since the actual memory load or store in a patched sequence often occurs on
subsequent instructions rather than the first, wouldn't they lose this flag
and incorrectly bypass KASAN checks during JIT compilation?
Reference:
https://lore.kernel.org/bpf/[email protected]/
---
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/26978380520
