kernel/linux.git/tools/lib/bpf/gen_loader.c, branch v7.2-rc2

libbpf: Guard add_data() against size overflow

2026-06-02T16:46:52+00:00

add_data() computes size8 = roundup(size, 8) and then hands size8 to realloc_data_buf() before doing memcpy(gen->data_cur, data, size) with the original size. A wrapped size8 passes through the realloc_data_buf() INT32_MAX check. Harden this against overflow, though not realistic to happen in practice. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260602133052.423725-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Skip max_entries override on signed loaders

2026-06-02T01:36:40+00:00

bpf_gen__map_create() lets the host-supplied loader ctx override a map's max_entries at runtime (map_desc[idx].max_entries, when non-zero). This is how the light skeleton sizes maps to the target machine, but it happens after emit_signature_match() and is covered by neither the signed loader instructions nor the hashed blob. For a signed loader this means an untrusted host can re-dimension the program's maps, outside what the signature attests to. Gate the override on gen_hash so signed loaders use the signer-provided max_entries baked into the blob. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-6-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Skip initial_value override on signed loaders

2026-06-02T01:36:40+00:00

bpf_gen__map_update_elem() emits code that, when the host-supplied loader ctx provides a non-NULL map_desc[idx].initial_value, overwrites the blob value with bytes read from the host (bpf_copy_from_user / bpf_probe_read_kernel) before the BPF_MAP_UPDATE_ELEM that populates the program's .data/.rodata/.bss maps. This override runs after emit_signature_match() has validated map->sha[], and initial_value is part of neither the signed loader instructions nor the hashed data blob. For a signed loader this lets an untrusted host substitute global-variable contents into a program whose code carries a valid signature, thus weakening what the signature attests to. The blob already contains the signer-provided value (added via add_data() and covered by the embedded, signed hash), so simply skip emitting the override for signed loaders (gen_hash). Runtime initialization stays available for the unsigned light-skeleton path as before. The jump offsets within the override block are internal to it, so guarding the whole block leaves them unchanged. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-5-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Reject non-exclusive metadata maps in the signed loader

2026-06-02T01:36:40+00:00

The loader verifies map->sha against the metadata hash in its instructions. map->sha is calculated when BPF_OBJ_GET_INFO_BY_FD is called on the frozen map. While the map is frozen, the /signed loader/ must also ensure the map is exclusive, as, without exclusivity (which a hostile host could just omit when loading the loader), another BPF program with map access can mutate the contents afterwards, so the check passes on stale data. With the extra check as part of the signed loader, it now refuses to move on with map->sha validation if the host set it up wrongly. Fixes: fb2b0e290147 ("libbpf: Update light skeleton for signing") Signed-off-by: KP Singh Co-developed-by: Daniel Borkmann Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Skip endianness swap when loader generation failed

2026-06-01T00:48:27+00:00

bpf_gen__prog_load() byte-swaps the program insns and the {func,line}_info and CO-RE relo blobs in place for cross-endian targets. The blob offsets come from add_data(), which returns 0 on failure: realloc_data_buf() either frees and NULLs gen->data_start (realloc OOM) or returns early on an already-latched gen->error, leaving a stale, possibly too-small buffer. Neither bswap site checked for this. With gen->swapped_endian set and a failed generation, "gen->data_start + off" becomes NULL + 0. Guard the same way via !gen->error so they are skipped once generation has failed. Fixes: 8ca3323dce43 ("libbpf: Support creating light skeleton of either endianness") Reported-by: sashiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529162829.315921-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Also reset {insn,data}_cur on realloc failure

2026-06-01T00:47:48+00:00

realloc_insn_buf() as well as realloc_data_buf() free and NULL gen->insn_start / gen->data_start on -ENOMEM but leave gen->insn_cur / gen->data_cur pointing into the old, freed buffer. Just reset the cursors to NULL alongside the base pointers so the freed state is coherent. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-3-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Skip hash computation when loader generation failed

2026-06-01T00:47:48+00:00

bpf_gen__finish() calls compute_sha_update_offsets() gated only on the gen_hash option, without first consulting gen->error. On a failed generation this is buggy: a failed realloc_data_buf() sets gen->data_start to NULL (leaving gen->data_cur dangling), so compute_sha_update_offsets() runs libbpf_sha256() over a NULL buffer with a bogus length; a failed realloc_insn_buf() likewise sets gen->insn_start to NULL and the hash immediates get patched through that NULL base. The computed program is discarded in either case, since the following "if (!gen->error)" block does not publish opts->insns once an error is set. Thus, skip the hash pass when generation has already failed. Fixes: ea923080c145 ("libbpf: Embed and verify the metadata hash in the loader") Reported-by: sashiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: Drop redundant self-loop in emit_check_err

2026-06-01T00:47:48+00:00

When the cleanup-label jump offset does not fit in s16, emit_check_err() sets gen->error = -ERANGE and then emits a BPF_JMP_IMM(BPF_JA, 0, 0, -1) self-loop. The latter emit() is dead: gen->error is assigned on the preceding line, and emit() then bails out early in realloc_insn_buf() the moment gen->error is set, so the jump is never written into the instruction stream. gen->error alone already marks the generation as failed. This is a follow-up to 7dd62566e0d1 ("libbpf: fix off-by-one in emit_signature_match jump offset") which removed the jump in emit_signature_match() but not in other locations. Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260529094119.307264-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov

libbpf: fix off-by-one in emit_signature_match jump offset

2026-05-23T14:49:22+00:00

The offset for the cleanup-label jump is computed before the MOV R7 instruction is emitted, but the JMP lands after it. Account for the extra insn in the offset calculation (-2 instead of -1). Drop the redundant self-loop in the else branch; gen->error = -ERANGE already marks the generation as failed. Fixes: fb2b0e290147 ("libbpf: Update light skeleton for signing") Signed-off-by: KP Singh Link: https://lore.kernel.org/r/20260522215337.662271-2-kpsingh@kernel.org Signed-off-by: Alexei Starovoitov

libbpf: move libbpf_errstr() into libbpf_utils.c

2025-10-01T22:27:25+00:00

Get rid of str_err.{c,h} by moving implementation of libbpf_errstr() into libbpf_utils.c and declarations into libbpf_internal.h. Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20251001171326.3883055-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov Acked-by: Eduard Zingerman