BPF indirect jumps #10105

kernel-patches-daemon-bpf · 2025-10-26T19:32:10Z

Pull request for series with
subject: BPF indirect jumps
version: 7
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1015970

kernel-patches-daemon-bpf · 2025-10-26T19:32:11Z

Upstream branch: e758657
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1015970
version: 7

kernel-patches-review-bot · 2025-10-26T19:41:38Z

commit a9c3be399ed61c8410c2586ec9be609f66d03e16
Author: Anton Protopopov <[email protected]>

libbpf: support llvm-generated indirect jumps

This patch adds support for LLVM-generated indirect jumps in BPF programs
by processing .jumptables ELF sections and creating BPF_MAP_TYPE_INSN_ARRAY
maps to store jump table entries with adjusted offsets for subprograms.

> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b90574f39..2127f11c9 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -6144,6 +6192,157 @@ static void poison_kfunc_call(struct bpf_program *prog, int relo_idx,
>  	insn->imm = POISON_CALL_KFUNC_BASE + ext_idx;
>  }
>
> +static int find_jt_map(struct bpf_object *obj, struct bpf_program *prog, int sym_off)
> +{
> +	size_t i;
> +
> +	for (i = 0; i < obj->jumptable_map_cnt; i++) {
> +		/*
> +		 * This might happen that same offset is used for two different
> +		 * programs (as jump tables can be the same). However, for
> +		 * different programs different maps should be created.
> +		 */
> +		if (obj->jumptable_maps[i].sym_off == sym_off &&
> +		    obj->jumptable_maps[i].prog == prog)
> +			return obj->jumptable_maps[i].fd;
> +	}
> +
> +	return -ENOENT;
> +}
> +
> +static int add_jt_map(struct bpf_object *obj, struct bpf_program *prog, int sym_off, int map_fd)
> +{
> +	size_t new_cnt = obj->jumptable_map_cnt + 1;
> +	size_t size = sizeof(obj->jumptable_maps[0]);
> +	void *tmp;
> +
> +	tmp = libbpf_reallocarray(obj->jumptable_maps, new_cnt, size);
> +	if (!tmp)
> +		return -ENOMEM;
> +
> +	obj->jumptable_maps = tmp;
> +	obj->jumptable_maps[new_cnt - 1].prog = prog;
> +	obj->jumptable_maps[new_cnt - 1].sym_off = sym_off;
> +	obj->jumptable_maps[new_cnt - 1].fd = map_fd;
> +	obj->jumptable_map_cnt = new_cnt;
> +
> +	return 0;
> +}
> +
> +static int find_subprog_idx(struct bpf_program *prog, int insn_idx)
> +{
> +	int i;
> +
> +	if (insn_idx < 0 || insn_idx >= prog->insns_cnt)
> +		return -1;
> +
> +	for (i = prog->subprog_cnt - 1; i >= 0; i--) {
> +		if (insn_idx >= prog->subprogs[i].sub_insn_off)
> +			return i;
> +	}
> +
> +	return -1;
> +}
> +
> +static int create_jt_map(struct bpf_object *obj, struct bpf_program *prog, struct reloc_desc *relo)
> +{
> +	const __u32 jt_entry_size = 8;
> +	int sym_off = relo->sym_off;
> +	int jt_size = relo->sym_size;
> +	__u32 max_entries = jt_size / jt_entry_size;
> +	__u32 value_size = sizeof(struct bpf_insn_array_value);
> +	struct bpf_insn_array_value val = {};
> +	int subprog_idx;
> +	int map_fd, err;
> +	__u64 insn_off;
> +	__u64 *jt;
> +	__u32 i;
> +
> +	map_fd = find_jt_map(obj, prog, sym_off);
> +	if (map_fd >= 0)
> +		return map_fd;
> +
> +	if (sym_off % jt_entry_size) {
> +		pr_warn("jumptable start %d should be multiple of %u\n",
> +			sym_off, jt_entry_size);
> +		return -EINVAL;
> +	}
> +
> +	if (jt_size % jt_entry_size) {
> +		pr_warn("jumptable size %d should be multiple of %u\n",
> +			jt_size, jt_entry_size);
> +		return -EINVAL;
> +	}
> +
> +	map_fd = bpf_map_create(BPF_MAP_TYPE_INSN_ARRAY, ".jumptables",
> +				4, value_size, max_entries, NULL);
> +	if (map_fd < 0)
> +		return map_fd;
> +
> +	if (!obj->jumptables_data) {
> +		pr_warn("map '.jumptables': ELF file is missing jump table data\n");
> +		err = -EINVAL;
> +		goto err_close;
> +	}
> +	if (sym_off + jt_size > obj->jumptables_data_sz) {
> +		pr_warn("jumptables_data size is %zd, trying to access %d\n",
> +			obj->jumptables_data_sz, sym_off + jt_size);
> +		err = -EINVAL;
> +		goto err_close;
> +	}
> +
> +	jt = (__u64 *)(obj->jumptables_data + sym_off);
> +	for (i = 0; i < max_entries; i++) {
> +		/*
> +		 * The offset should be made to be relative to the beginning of
> +		 * the main function, not the subfunction.
> +		 */
> +		insn_off = jt[i]/sizeof(struct bpf_insn);
> +		if (!prog->subprogs) {
> +			insn_off -= prog->sec_insn_off;
> +		} else {
> +			subprog_idx = find_subprog_idx(prog, relo->insn_idx);
> +			if (subprog_idx < 0) {
> +				pr_warn("invalid jump insn idx[%d]: %d, no subprog found\n",
> +					i, relo->insn_idx);
> +				err = -EINVAL;
> +			}
> +			insn_off -= prog->subprogs[subprog_idx].sec_insn_off;
> +			insn_off += prog->subprogs[subprog_idx].sub_insn_off;
                        ^^^^

Does this code need a goto err_close when find_subprog_idx() returns
a negative value? Currently when subprog_idx is negative, the code sets
err but continues executing, which leads to an array underflow accessing
prog->subprogs[subprog_idx] with a negative index. Additionally, the
map_fd created earlier remains open because the error path doesn't reach
err_close.

> +		}
> +
> +		/*
> +		 * LLVM-generated jump tables contain u64 records, however
> +		 * should contain values that fit in u32.
> +		 */
> +		if (insn_off > UINT32_MAX) {
> +			pr_warn("invalid jump table value %llx at offset %d\n",
> +				jt[i], sym_off + i);
> +			err = -EINVAL;
> +			goto err_close;
> +		}
> +
> +		val.orig_off = insn_off;
> +		err = bpf_map_update_elem(map_fd, &i, &val, 0);
> +		if (err)
> +			goto err_close;
> +	}
> +
> +	err = bpf_map_freeze(map_fd);
> +	if (err)
> +		goto err_close;
> +
> +	err = add_jt_map(obj, prog, sym_off, map_fd);
> +	if (err)
> +		goto err_close;
> +
> +	return map_fd;
> +
> +err_close:
> +	close(map_fd);
> +	return err;
> +}

[ ... ]

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

In-Reply-To-Subject: libbpf: support llvm-generated indirect jumps
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18822724480

kernel-patches-review-bot · 2025-10-26T19:41:59Z

commit 918f2fdf42ffa9374fe02cf17de0fae30bf30df9
Author: Anton Protopopov <[email protected]>

bpf, docs: do not state that indirect jumps are not supported

This commit removes documentation about an unsupported BPF instruction,
claiming it is outdated. The commit message refers to "indirect jump
instruction" support.

> diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/linux-notes.rst
> index 00d2693de..64ac146a9 100644
> --- a/Documentation/bpf/linux-notes.rst
> +++ b/Documentation/bpf/linux-notes.rst
> @@ -12,14 +12,6 @@ Byte swap instructions
>
>  ``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
>
> -Jump instructions
> -=================
> -
> -``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
> -integer would be read from a specified register, is not currently supported
> -by the verifier.  Any programs with this instruction will fail to load
> -until such support is added.
> -

Does this documentation removal conflate two different instructions?

The removed text explicitly documents that BPF_CALL | BPF_X | BPF_JMP
(opcode 0x8d) is unsupported. This instruction would perform indirect
calls where "the helper function integer would be read from a specified
register."

However, the recent indirect jump support added in commit d2bc38ce4
("bpf, x86: add support for indirect jumps") implements a different
instruction: BPF_JMP | BPF_X | BPF_JA (opcode 0x0d), not 0x8d.

The verifier still rejects BPF_CALL instructions with BPF_X source at
kernel/bpf/verifier.c in do_check():

    if (opcode == BPF_CALL) {
        if (BPF_SRC(insn->code) != BPF_K ||
            ...
            verbose(env, "BPF_CALL uses reserved fields\n");
            return -EINVAL;
        }

This check requires BPF_CALL to use BPF_K (immediate) source, not BPF_X
(register source). Therefore instruction 0x8d remains unsupported.

Should the documentation about 0x8d be retained, since indirect calls
(BPF_CALL with register source) are still unsupported, even though
indirect jumps (BPF_JA with register source) are now supported?

Note: Documentation/bpf/clang-notes.rst:26-27 still correctly documents
that "BPF_CALL | BPF_X | BPF_JMP (0x8d) ... is not supported by the
Linux kernel verifier."

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

In-Reply-To-Subject: bpf, docs: do not state that indirect jumps are not supported
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18822724480

kernel-patches-review-bot · 2025-10-26T19:42:52Z

commit 75b77130dd12b88b947d69ea906b287c2613224d
Author: Anton Protopopov <[email protected]>

bpf, x86: add new map type: instructions array

This patch adds a new BPF map type BPF_MAP_TYPE_INSN_ARRAY to track
instruction offset mappings during BPF program verification and JIT
compilation. The map tracks how original instruction offsets are
transformed through verification (xlated offsets) and JIT compilation
(jitted offsets).

> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index e53cda0aa..b64c2382f 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h

[ ... ]

> +typedef void (*update_insn_ptr_func_t)(void *jit_priv, u32 xlated_off, u32 *jitted_off, long *ip);
> +
> +#ifdef CONFIG_BPF_SYSCALL
> +void bpf_prog_update_insn_ptrs(struct bpf_prog *prog, void *jit_priv,
> +			       update_insn_ptr_func_t update_insn_ptr);
> +#else
> +static inline void
> +bpf_prog_update_insn_ptrs(struct bpf_prog *prog, void *jit_priv,
> +			  update_insn_ptr_func_t update_insn_ptr);
                                                                    ^

There's a semicolon after the function parameter list that will cause
a compilation error. In C, inline function definitions should not have
a semicolon between the parameter list and the opening brace. This will
break builds when CONFIG_BPF_SYSCALL is not defined.

Should this be:

static inline void
bpf_prog_update_insn_ptrs(struct bpf_prog *prog, void *jit_priv,
			  update_insn_ptr_func_t update_insn_ptr)
{
}

> +{
> +}
> +#endif
> +
>  #endif /* _LINUX_BPF_H */

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

In-Reply-To-Subject: bpf, x86: add new map type: instructions array
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18822724480

kernel-patches-review-bot · 2025-10-26T19:43:46Z

commit d2bc38ce43cd5c7f1a2305128c7a5422965ca130
Author: Anton Protopopov <[email protected]>

bpf, x86: add support for indirect jumps

This patch adds support for indirect jumps in BPF programs via a new
gotox instruction that jumps to addresses loaded from instruction array
maps. The verifier introduces PTR_TO_INSN register type to track jump
targets and validates that indirect jumps only target valid instructions
within the current subprogram.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index ae017c032..c74665207 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c

[ ... ]

> @@ -17838,6 +17851,197 @@ static struct bpf_iarray *iarray_realloc(struct bpf_iarray *old, size_t n_elem)
>  	return new;
>  }
>
> +static int copy_insn_array(struct bpf_map *map, u32 start, u32 end, u32 *items)
> +{
> +	struct bpf_insn_array_value *value;
> +	u32 i;
> +
> +	for (i = start; i <= end; i++) {
> +		value = map->ops->map_lookup_elem(map, &i);
> +		if (!value)
> +			return -EINVAL;
> +		items[i - start] = value->xlated_off;
> +	}
> +	return 0;
> +}
> +
> +static int cmp_ptr_to_u32(const void *a, const void *b)
> +{
> +	return *(u32 *)a - *(u32 *)b;
> +}

Can this comparison function overflow? The xlated_off field can contain
either instruction indices (0 to BPF_COMPLEXITY_LIMIT_INSNS) or the
special value INSN_DELETED which is defined as (u32)-1 (0xFFFFFFFF).

When comparing INSN_DELETED with a small value like 0, the subtraction
0xFFFFFFFF - 0 = 0xFFFFFFFF gets implicitly cast to int, which produces
-1 instead of a positive value. This causes INSN_DELETED entries to
incorrectly sort before valid instruction offsets.

While INSN_DELETED entries should eventually be rejected as invalid jump
targets in visit_gotox_insn(), the incorrect sorting happens first in
sort_insn_array_uniq() and could cause the deduplication logic to fail
when the same values appear non-adjacent after the broken sort.

> +
> +static int sort_insn_array_uniq(u32 *items, int cnt)
> +{
> +	int unique = 1;
> +	int i;
> +
> +	sort(items, cnt, sizeof(items[0]), cmp_ptr_to_u32, NULL);
> +
> +	for (i = 1; i < cnt; i++)
> +		if (items[i] != items[unique - 1])
> +			items[unique++] = items[i];
> +
> +	return unique;
> +}

[ ... ]

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

In-Reply-To-Subject: bpf, x86: add support for indirect jumps
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/18822724480

kernel-patches-daemon-bpf · 2025-10-26T19:47:53Z

Forwarding comment 3448859477 via email
In-Reply-To: [email protected]
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

kernel-patches-daemon-bpf · 2025-10-26T19:47:54Z

Forwarding comment 3448859836 via email
In-Reply-To: [email protected]
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

kernel-patches-daemon-bpf · 2025-10-26T19:47:56Z

Forwarding comment 3448860672 via email
In-Reply-To: [email protected]
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

kernel-patches-daemon-bpf · 2025-10-26T19:47:57Z

Forwarding comment 3448861544 via email
In-Reply-To: [email protected]
Patch: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/

kernel-patches-daemon-bpf · 2025-10-27T17:06:07Z

Upstream branch: ff88079
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1015970
version: 7

On bpf(BPF_PROG_LOAD) syscall user-supplied BPF programs are translated by the verifier into "xlated" BPF programs. During this process the original instructions offsets might be adjusted and/or individual instructions might be replaced by new sets of instructions, or deleted. Add a new BPF map type which is aimed to keep track of how, for a given program, the original instructions were relocated during the verification. Also, besides keeping track of the original -> xlated mapping, make x86 JIT to build the xlated -> jitted mapping for every instruction listed in an instruction array. This is required for every future application of instruction arrays: static keys, indirect jumps and indirect calls. A map of the BPF_MAP_TYPE_INSN_ARRAY type must be created with a u32 keys and value of size 8. The values have different semantics for userspace and for BPF space. For userspace a value consists of two u32 values – xlated and jitted offsets. For BPF side the value is a real pointer to a jitted instruction. On map creation/initialization, before loading the program, each element of the map should be initialized to point to an instruction offset within the program. Before the program load such maps should be made frozen. After the program verification xlated and jitted offsets can be read via the bpf(2) syscall. If a tracked instruction is removed by the verifier, then the xlated offset is set to (u32)-1 which is considered to be too big for a valid BPF program offset. One such a map can, obviously, be used to track one and only one BPF program. If the verification process was unsuccessful, then the same map can be re-used to verify the program with a different log level. However, if the program was loaded fine, then such a map, being frozen in any case, can't be reused by other programs even after the program release. Example. Consider the following original and xlated programs: Original prog: Xlated prog: 0: r1 = 0x0 0: r1 = 0 1: *(u32 *)(r10 - 0x4) = r1 1: *(u32 *)(r10 -4) = r1 2: r2 = r10 2: r2 = r10 3: r2 += -0x4 3: r2 += -4 4: r1 = 0x0 ll 4: r1 = map[id:88] 6: call 0x1 6: r1 += 272 7: r0 = *(u32 *)(r2 +0) 8: if r0 >= 0x1 goto pc+3 9: r0 <<= 3 10: r0 += r1 11: goto pc+1 12: r0 = 0 7: r6 = r0 13: r6 = r0 8: if r6 == 0x0 goto +0x2 14: if r6 == 0x0 goto pc+4 9: call 0x76 15: r0 = 0xffffffff8d2079c0 17: r0 = *(u64 *)(r0 +0) 10: *(u64 *)(r6 + 0x0) = r0 18: *(u64 *)(r6 +0) = r0 11: r0 = 0x0 19: r0 = 0x0 12: exit 20: exit An instruction array map, containing, e.g., instructions [0,4,7,12] will be translated by the verifier to [0,4,13,20]. A map with index 5 (the middle of 16-byte instruction) or indexes greater than 12 (outside the program boundaries) would be rejected. The functionality provided by this patch will be extended in consequent patches to implement BPF Static Keys, indirect jumps, and indirect calls. Signed-off-by: Anton Protopopov <[email protected]> Reviewed-by: Eduard Zingerman <[email protected]>

Add the following selftests for new insn_array map: * Incorrect instruction indexes are rejected * Two programs can't use the same map * BPF progs can't operate the map * no changes to code => map is the same * expected changes when instructions are added * expected changes when instructions are deleted * expected changes when multiple functions are present Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

When bpf_jit_harden is enabled, all constants in the BPF code are blinded to prevent JIT spraying attacks. This happens during JIT phase. Adjust all the related instruction arrays accordingly. Signed-off-by: Anton Protopopov <[email protected]> Reviewed-by: Eduard Zingerman <[email protected]>

Add a specific test for instructions arrays with blinding enabled. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

Currently the emit_indirect_jump() function only accepts one of the RAX, RCX, ..., RBP registers as the destination. Make it to accept R8, R9, ..., R15 as well, and make callers to pass BPF registers, not native registers. This is required to enable indirect jumps support in eBPF. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

Add support for a new instruction BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=0 which does an indirect jump to a location stored in Rx. The register Rx should have type PTR_TO_INSN. This new type assures that the Rx register contains a value (or a range of values) loaded from a correct jump table – map of type instruction array. For example, for a C switch LLVM will generate the following code: 0: r3 = r1 # "switch (r3)" 1: if r3 > 0x13 goto +0x666 # check r3 boundaries 2: r3 <<= 0x3 # adjust to an index in array of addresses 3: r1 = 0xbeef ll # r1 is PTR_TO_MAP_VALUE, r1->map_ptr=M 5: r1 += r3 # r1 inherits boundaries from r3 6: r1 = *(u64 *)(r1 + 0x0) # r1 now has type INSN_TO_PTR 7: gotox r1 # jit will generate proper code Here the gotox instruction corresponds to one particular map. This is possible however to have a gotox instruction which can be loaded from different maps, e.g. 0: r1 &= 0x1 1: r2 <<= 0x3 2: r3 = 0x0 ll # load from map M_1 4: r3 += r2 5: if r1 == 0x0 goto +0x4 6: r1 <<= 0x3 7: r3 = 0x0 ll # load from map M_2 9: r3 += r1 A: r1 = *(u64 *)(r3 + 0x0) B: gotox r1 # jump to target loaded from M_1 or M_2 During check_cfg stage the verifier will collect all the maps which point to inside the subprog being verified. When building the config, the high 16 bytes of the insn_state are used, so this patch (theoretically) supports jump tables of up to 2^16 slots. During the later stage, in check_indirect_jump, it is checked that the register Rx was loaded from a particular instruction array. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

Add support for indirect jump instruction. Example output from bpftool: 0: (79) r3 = *(u64 *)(r1 +0) 1: (25) if r3 > 0x4 goto pc+666 2: (67) r3 <<= 3 3: (18) r1 = 0xffffbeefspameggs 5: (0f) r1 += r3 6: (79) r1 = *(u64 *)(r1 +0) 7: (0d) gotox r1 Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

The linux-notes.rst states that indirect jump instruction "is not currently supported by the verifier". Remove this part as outdated. Signed-off-by: Anton Protopopov <[email protected]>

For v4 instruction set LLVM is allowed to generate indirect jumps for switch statements and for 'goto *rX' assembly. Every such a jump will be accompanied by necessary metadata, e.g. (`llvm-objdump -Sr ...`): 0: r2 = 0x0 ll 0000000000000030: R_BPF_64_64 BPF.JT.0.0 Here BPF.JT.1.0 is a symbol residing in the .jumptables section: Symbol table: 4: 0000000000000000 240 OBJECT GLOBAL DEFAULT 4 BPF.JT.0.0 The -bpf-min-jump-table-entries llvm option may be used to control the minimal size of a switch which will be converted to an indirect jumps. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

Teach bpftool to recognize instruction array map type. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Quentin Monnet <[email protected]>

Add a set of tests to validate core gotox functionality without need to rely on compilers. Signed-off-by: Anton Protopopov <[email protected]>

Add C-level selftests for indirect jumps to validate LLVM and libbpf functionality. The tests are intentionally disabled, to be run locally by developers, but will not make the CI red. Signed-off-by: Anton Protopopov <[email protected]>

kernel-patches-daemon-bpf · 2025-10-27T22:19:24Z

Upstream branch: ff88079
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1015970
version: 7

kernel-patches-daemon-bpf · 2025-10-28T02:36:00Z

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=1015970 expired. Closing PR.

kernel-patches-daemon-bpf bot added new bpf-next V7 labels Oct 26, 2025

kernel-patches-review-bot bot added the ai-review label Oct 26, 2025

kernel-patches-daemon-bpf bot added V7-ci-fail and removed ai-review labels Oct 26, 2025

kernel-patches-daemon-bpf bot force-pushed the bpf-next_base branch from ecdeefe to 10ce4bd Compare October 27, 2025 17:05

kernel-patches-daemon-bpf bot force-pushed the series/1015970=>bpf-next branch from 05cb10d to 2e00b29 Compare October 27, 2025 17:06

kernel-patches-daemon-bpf bot added V7-ci-pass and removed V7-ci-fail labels Oct 27, 2025

aspsk added 10 commits October 27, 2025 15:19

selftests/bpf: test instructions arrays with blinding

e573ab3

Add a specific test for instructions arrays with blinding enabled. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Eduard Zingerman <[email protected]>

bpf, docs: do not state that indirect jumps are not supported

3f566bd

The linux-notes.rst states that indirect jump instruction "is not currently supported by the verifier". Remove this part as outdated. Signed-off-by: Anton Protopopov <[email protected]>

bpftool: Recognize insn_array map type

8b9d26e

Teach bpftool to recognize instruction array map type. Signed-off-by: Anton Protopopov <[email protected]> Acked-by: Quentin Monnet <[email protected]>

aspsk added 2 commits October 27, 2025 15:19

selftests/bpf: add new verifier_gotox test

b60fc4d

Add a set of tests to validate core gotox functionality without need to rely on compilers. Signed-off-by: Anton Protopopov <[email protected]>

kernel-patches-daemon-bpf bot force-pushed the series/1015970=>bpf-next branch from 2e00b29 to 20e3239 Compare October 27, 2025 22:19

kernel-patches-daemon-bpf bot added changes-requested and removed new labels Oct 28, 2025

kernel-patches-daemon-bpf bot closed this Oct 28, 2025

Uh oh!

BPF indirect jumps #10105

BPF indirect jumps #10105

Uh oh!

Conversation

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-review-bot bot commented Oct 26, 2025

Uh oh!

kernel-patches-review-bot bot commented Oct 26, 2025

Uh oh!

kernel-patches-review-bot bot commented Oct 26, 2025

Uh oh!

kernel-patches-review-bot bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 26, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 27, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 27, 2025

Uh oh!

kernel-patches-daemon-bpf bot commented Oct 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant