[PATCH AUTOSEL 6.18-5.15] libbpf: Also reset {insn,data}_cur on realloc failure

[PATCH AUTOSEL 6.18-5.15] libbpf: Also reset {insn,data}_cur on realloc failure

[Sasha Levin]

From: Daniel Borkmann <daniel@iogearbox.net>

[ Upstream commit d2f7bd066ed492aeaf82864fbf1f06770f9d9f9d ]

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 <daniel@iogearbox.net>
Link: https://lore.kernel.org/r/20260529094119.307264-3-daniel@iogearbox.net
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background search for the commit hash finished: `git log --grep` did
not turn up **"libbpf: Also reset {insn,data}_cur on realloc failure"**
in this 6.18.44 tree. The matches were unrelated "reset" commits in
other subsystems, which fits — the fix is not applied here yet.

The earlier analysis still holds: this is patch 3/3 of Daniel Borkmann’s
gen_loader series; patches 2 (hash skip) and the endianness guard are
already in this tree, but the root cursor-reset fix is missing. It’s a
small, real userspace memory-safety fix on the OOM path and should be
backported.

**YES**

 tools/lib/bpf/gen_loader.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
index d41defa1936d3..4e2d25e024af4 100644
--- a/tools/lib/bpf/gen_loader.c
+++ b/tools/lib/bpf/gen_loader.c
@@ -63,6 +63,7 @@ static int realloc_insn_buf(struct bpf_gen *gen, __u32 size)
 		gen->error = -ENOMEM;
 		free(gen->insn_start);
 		gen->insn_start = NULL;
+		gen->insn_cur = NULL;
 		return -ENOMEM;
 	}
 	gen->insn_start = insn_start;
@@ -86,6 +87,7 @@ static int realloc_data_buf(struct bpf_gen *gen, __u32 size)
 		gen->error = -ENOMEM;
 		free(gen->data_start);
 		gen->data_start = NULL;
+		gen->data_cur = NULL;
 		return -ENOMEM;
 	}
 	gen->data_start = data_start;
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.15] libbpf: Also reset {insn,data}_cur on realloc failure

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing `gen->error` check in `bpf_gen__finish()` leads to a NULL pointer dereference in `compute_sha_update_offsets()` if a previous allocation failed.
- [High] Missing `gen->error` check in `bpf_gen__prog_load()` leads to a NULL pointer dereference during endianness swapping after an allocation failure.
--

commit d36df279d8dfc0fe65a516d12685c54faba8d9da
Author: Daniel Borkmann <daniel@iogearbox.net>

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

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.

Link: https://lore.kernel.org/r/20260529094119.307264-3-daniel@iogearbox.net

> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> index cd5c2543f54d8..8722ecc023819 100644
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -63,6 +63,7 @@ static int realloc_insn_buf(struct bpf_gen *gen, __u32 size)
>  		gen->error = -ENOMEM;
>  		free(gen->insn_start);
>  		gen->insn_start = NULL;
> +		gen->insn_cur = NULL;
>  		return -ENOMEM;
>  	}

[Severity: High]
This is a pre-existing issue, but missing a gen->error check in
bpf_gen__finish() leads to a NULL pointer dereference in
compute_sha_update_offsets() if this allocation fails.

If a buffer allocation fails here, gen->error is set and gen->insn_start is
freed and set to NULL. The libbpf loader relies on bpf_gen__finish() to return
the error at the end of the operation, but it unconditionally calls
compute_sha_update_offsets() before checking gen->error:

tools/lib/bpf/gen_loader.c:bpf_gen__finish() {
    ...
	if (OPTS_GET(gen->opts, gen_hash, false))
		compute_sha_update_offsets(gen);

	pr_debug("gen: finish %s\n", errstr(gen->error));
	if (!gen->error) {
    ...
}

Which then directly dereferences the NULL gen->insn_start:

tools/lib/bpf/gen_loader.c:compute_sha_update_offsets() {
    ...
	for (i = 0; i < SHA256_DWORD_SIZE; i++) {
		struct bpf_insn *insn =
			(struct bpf_insn *)(gen->insn_start + gen->hash_insn_offset[i]);
		sha_dw = tgt_endian(sha[i]);
		insn[0].imm = (__u32)sha_dw;
    ...
}

Should bpf_gen__finish() check gen->error before calling
compute_sha_update_offsets()?

[ ... ]

> @@ -86,6 +87,7 @@ static int realloc_data_buf(struct bpf_gen *gen, __u32 size)
>  		gen->error = -ENOMEM;
>  		free(gen->data_start);
>  		gen->data_start = NULL;
> +		gen->data_cur = NULL;
>  		return -ENOMEM;
>  	}

[Severity: High]
This is a pre-existing issue, but missing a gen->error check in
bpf_gen__prog_load() leads to a NULL pointer dereference during endianness
swapping if this allocation fails.

bpf_gen__prog_load() dynamically allocates buffers by calling add_data(), which
eventually calls realloc_data_buf(). If this allocation fails, gen->error is
set to -ENOMEM, gen->data_start is set to NULL, and add_data() returns 0.

However, bpf_gen__prog_load() ignores gen->error and continues execution.
If gen->swapped_endian is true, it attempts to iterate over instructions
stored in gen->data_start, directly dereferencing the NULL pointer:

tools/lib/bpf/gen_loader.c:bpf_gen__prog_load() {
    ...
	insns_off = add_data(gen, insns, insn_cnt * sizeof(struct bpf_insn));
    ...
	/* convert blob insns to target endianness */
	if (gen->swapped_endian) {
		struct bpf_insn *insn = gen->data_start + insns_off;
		int i;

		for (i = 0; i < insn_cnt; i++, insn++)
			bpf_insn_bswap(insn);
	}
    ...
}

Similarly, the info_blob_bswap() helper function also dereferences the
NULL gen->data_start buffer:

tools/lib/bpf/gen_loader.c:info_blob_bswap() {
	struct bpf_func_info *fi = gen->data_start + func_info;
    ...
	for (i = 0; i < load_attr->func_info_cnt; i++)
		bpf_func_info_bswap(fi++);
    ...
}

Should bpf_gen__prog_load() check gen->error and abort early?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-44-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-6.1] libbpf: Add __NR_bpf definition for LoongArch

[Sasha Levin]

From: Tiezhu Yang <yangtiezhu@loongson.cn>

[ Upstream commit a4a5d4ee061240a1d39053db0a87f841d43277c0 ]

LoongArch uses the generic syscall table, where __NR_bpf is defined
as 280 in include/uapi/asm-generic/unistd.h.

To align with other architectures, add the __NR_bpf definition for
LoongArch to avoid a potential compilation failure: "error __NR_bpf
not defined. libbpf does not support your arch."

This is a follow up patch of:

  commit b0c47807d31d ("bpf: Add sparc support to tools and samples.")
  commit bad1926dd2f6 ("bpf, s390: fix build for libbpf and selftest suite")
  commit ca31ca8247e2 ("tools/bpf: fix perf build error with uClibc (seen on ARC)")
  commit e32cb12ff52a ("bpf, mips: Fix build errors about __NR_bpf undeclared")

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260526063936.16769-1-yangtiezhu@loongson.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `libbpf: Add __NR_bpf definition for
LoongArch`

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
`make kernelversion` → `6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[libbpf] [add] [__NR_bpf definition for LoongArch]`

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Tiezhu Yang `<yangtiezhu@loongson.cn>` (author)
- **Signed-off-by:** Andrii Nakryiko `<andrii@kernel.org>` (libbpf
  maintainer)
- **Link:** https://lore.kernel.org/bpf/20260526063936.16769-1-
  yangtiezhu@loongson.cn
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable tags
- Notable: maintainer Signed-off-by is a quality signal; no syzbot/user
  bug report

### Step 1.3: Body analysis
**Record:**
- **Bug:** When building libbpf/bpf tools on LoongArch with overridden
  `unistd.h` (perf build path), `__NR_bpf` is undefined and compilation
  fails with `#error __NR_bpf not defined. libbpf does not support your
  arch.`
- **Symptom:** Build failure (compile-time `#error`), not a runtime
  kernel crash
- **Root cause:** LoongArch uses the generic syscall table (`__NR_bpf` =
  280 in `asm-generic/unistd.h`), but the explicit arch fallback list in
  `tools/lib/bpf/bpf.c` and `tools/build/feature/test-bpf.c` was never
  updated for `__loongarch__`
- **Version info:** None in message; follow-up to arch-specific
  `__NR_bpf` additions dating from 2017–2021

### Step 1.4: Hidden bug fix?
**Record:** Yes — described as alignment/cleanup, but it is a **build
fix** preventing compilation failure on LoongArch, same class as prior
mips/ARC/s390/sparc fixes by the same pattern.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- `tools/lib/bpf/bpf.c`: +2 lines
- `tools/build/feature/test-bpf.c`: +2 lines
- **Total:** 4 insertions, 0 deletions
- **Functions affected:** None directly; modifies preprocessor fallback
  block before `sys_bpf()` / `main()`
- **Scope:** Single-purpose, two-file surgical fix

### Step 2.2: Code flow change
**Record:**
- **Hunk 1 (`bpf.c`):** Before → `#elif mips` then `#else #error`. After
  → adds `#elif defined(__loongarch__) #define __NR_bpf 280` before the
  error branch. Affects the `#ifndef __NR_bpf` fallback used when perf
  overrides `unistd.h`.
- **Hunk 2 (`test-bpf.c`):** Same preprocessor addition for bpf feature-
  detection compile test.

### Step 2.3: Bug mechanism
**Record:** **Build fix / missing arch definition (category
h-adjacent).** When `__NR_bpf` is not provided by headers (overridden
`unistd.h` path documented in `bpf.c`), LoongArch hits the `#else
#error` branch. Fix supplies the correct syscall number (280).

### Step 2.4: Fix quality
**Record:** Obviously correct — value 280 matches `include/uapi/asm-
generic/unistd.h` and `tools/arch/loongarch/include/uapi/asm/unistd.h`
(which includes `asm-generic/unistd.h`). Minimal, mirrors existing arch
entries (aarch64, arc also use 280). **Regression risk:** very low; only
affects preprocessor path when `__NR_bpf` is absent.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** `__NR_bpf` fallback block in `bpf.c` introduced in
e3ed2fef22b6 (2015). Arch entries added incrementally: sparc (b0c47807,
2017), s390 (bad1926dd, 2017), arc (ca31ca82, 2019), mips (e32cb12ff,
2021, same author). LoongArch omission is a long-standing gap, not a
recently introduced regression.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag. Referenced prerequisite commits all
exist in this tree (`b0c47807`, `bad1926dd`, `ca31ca82`, `e32cb12ff`
confirmed via `git merge-base --is-ancestor`).

### Step 3.3: File history
**Record:** Related LoongArch libbpf work already in tree:
`00883922ab404` (bpf_tracing.h), `29c66ad1c3ad1` (PT_REGS_CAST for
LoongArch). `seccomp_bpf.c` already defines `__NR_seccomp` for
`__loongarch__` (line 147). Standalone patch; not part of a multi-patch
series.

### Step 3.4: Author context
**Record:** Tiezhu Yang (Loongson) — prior `e32cb12ff52a2` mips
`__NR_bpf` fix in same files. Andrii Nakryiko (libbpf maintainer)
Signed-off-by.

### Step 3.5: Dependencies
**Record:** No hard dependencies beyond the existing `__NR_bpf` fallback
mechanism (present since 2015+). Applies standalone. Commit itself is
**not** in current branch (`git log --grep` returned empty).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:** `b4 am 20260526063936.16769-1-yangtiezhu@loongson.cn` found
thread at
https://patch.msgid.link/20260526063936.16769-1-yangtiezhu@loongson.cn.
Mbox contains only the patch (1 message, no replies). No stable
nominations or NAKs found. `b4 dig -c HEAD` failed (commit not in tree);
used message-id lookup instead.

### Step 4.2: Reviewers
**Record:** Andrii Nakryiko Signed-off-by on patch. No separate
Reviewed-by in mbox.

### Step 4.3: Bug report
**Record:** N/A — no external bug report or syzbot link. Author
documents expected compile error text.

### Step 4.4: Related patches
**Record:** Part of ongoing arch-by-arch `__NR_bpf` fallback additions.
Same author fixed mips identically in 2021. LoongArch bpf_tracing
support already merged separately.

### Step 4.5: Stable list history
**Record:** Not searched on lore stable list (WebFetch blocked by bot
protection). No stable discussion found in mbox.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** Preprocessor block only. Downstream: `sys_bpf()` in `bpf.c`
calls `syscall(__NR_bpf, ...)`. `test-bpf.c` `main()` calls
`syscall(__NR_bpf, BPF_PROG_LOAD, ...)`.

### Step 5.2: Callers
**Record:** `sys_bpf()` is the central libbpf syscall wrapper — used
throughout libbpf for all BPF operations. Only reached at runtime if
compilation succeeds; this patch affects **compile-time** availability
of `__NR_bpf`.

### Step 5.3: Callees
**Record:** `syscall(__NR_bpf, ...)` — requires correct arch syscall
number.

### Step 5.4: Reachability
**Record:** Triggered when building bpf tools (libbpf, perf, bpftool,
bpf selftests feature detection) on LoongArch hosts where `__NR_bpf` is
not defined by included headers. Userspace build path, not kernel
runtime.

### Step 5.5: Similar patterns
**Record:** `seccomp_bpf.c` already has `__loongarch__` syscall
fallbacks (`__NR_seccomp 277`). `bpf.c` and `test-bpf.c` are
inconsistent — LoongArch was missed. Same pattern fixed for mips, arc,
s390, sparc.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy code exists?
**Record:** **YES.** Current `tools/lib/bpf/bpf.c` lines 43–64 and
`tools/build/feature/test-bpf.c` lines 6–25 lack `__loongarch__` case
and fall through to `#error`. LoongArch arch support present since
`fa96b57c14906` (LoongArch build infrastructure). Bug has existed since
LoongArch tooling support without this define.

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Two identical 2-line hunks in
files that match the patch context. No conflicting recent churn in this
specific block.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix found. `git log --grep="Add __NR_bpf
definition for LoongArch"` returns empty on this branch.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** **tools/lib/bpf** (userspace libbpf shipped with kernel
sources). **Criticality:** IMPORTANT for bpf tooling; PERIPHERAL for
general kernel runtime (does not affect running kernel on non-LoongArch
or pre-built distros).

### Step 7.2: Activity
**Record:** LoongArch and libbpf actively maintained in 6.18.y (recent
LoongArch BPF/kprobes fixes; ongoing libbpf API work).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** LoongArch users building kernel bpf tools from source
(libbpf, perf, bpftool, bpf feature tests). Not universal; platform-
specific build issue.

### Step 8.2: Trigger conditions
**Record:** Compile libbpf/bpf tools on LoongArch when `__NR_bpf` is not
provided by headers (documented perf override path). Common for
developers/maintainers building from kernel tree on LoongArch hardware.
Unprivileged users can trigger only insofar as they can invoke a build.

### Step 8.3: Failure mode severity
**Record:** **Compile-time failure** (`#error` / undeclared `__NR_bpf`).
**Severity: MEDIUM** for affected users (cannot build tools); **LOW**
for general kernel stability (no runtime crash, corruption, or security
issue).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Enables bpf tool builds on LoongArch; closes obvious gap
  vs. other arches and vs. `seccomp_bpf.c` on same platform
- **Risk:** Very low — 4 lines, correct constant, no logic change
- **Ratio:** Favorable; classic stable build-fix backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real build failure on LoongArch (documented error path)
- Build fix — explicit stable exception category
- Tiny (4 lines), obviously correct (`__NR_bpf` = 280 verified in tree
  headers)
- Same pattern as mips/ARC/s390 fixes already in 6.18.44
- libbpf maintainer Signed-off-by
- Buggy code confirmed present in 6.18.44
- Prerequisites all in tree; standalone apply

**AGAINST backport:**
- No runtime kernel bug (tools-only build issue)
- Affects niche platform (LoongArch)
- No user bug reports or syzbot evidence
- No explicit stable nomination in review thread (thread had no replies)

**Unresolved:** Whether distro packagers always hit the
overridden-`unistd.h` path; author says "potential" failure, but
mechanism is well-established from `bpf.c` comment and prior arch fixes.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — syscall number matches `asm-
   generic/unistd.h`; maintainer SOB; mirrors proven prior arch fixes
2. Fixes real bug affecting users? **PASS** — compile failure for
   LoongArch bpf tool builds
3. Important issue? **PASS (moderate)** — build fix for platform
   developers; not crash/security, but stable explicitly accepts build
   fixes
4. Small and contained? **PASS** — 4 lines, 2 files
5. No new features/APIs? **PASS** — preprocessor define only
6. Can apply to local tree? **PASS** — buggy code present, clean apply
   expected

### Step 9.3: Exception category
**Record:** **BUILD FIX** — prevents compilation failure when building
libbpf/bpf tools on LoongArch.

### Step 9.4: Decision rationale
For Linux **6.18.44**, LoongArch is a supported architecture and bpf
tooling is actively used, but `tools/lib/bpf/bpf.c` and
`tools/build/feature/test-bpf.c` still lack the `__loongarch__` entry in
the `__NR_bpf` fallback table. This is the same class of fix as the mips
(`e32cb12ff52a2`) and ARC (`ca31ca8247e2`) commits already in this tree.
The fix is trivial, correct, and low-risk. While severity is build-time
rather than runtime, stable trees routinely accept such arch-specific
build fixes — especially when they unblock tool compilation on a
supported platform.

---

## Verification

- **[Phase 1]** `git describe HEAD` → v6.18.44; parsed subject, tags,
  body from user-provided commit and mbox
- **[Phase 2]** Read `tools/lib/bpf/bpf.c` lines 39–65; read
  `tools/build/feature/test-bpf.c` full file; confirmed 4-line diff,
  preprocessor-only change
- **[Phase 3]** `git blame -L 43,65 tools/lib/bpf/bpf.c` — fallback
  block history traced to 2015; mips fix e32cb12ff52a2 by same author
- **[Phase 3]** `git merge-base --is-ancestor b0c47807d31d HEAD` →
  prerequisite in tree
- **[Phase 3]** `git log --grep="Add __NR_bpf definition for LoongArch"`
  → not in branch
- **[Phase 3]** `git log --author="Tiezhu Yang" -- tools/lib/bpf/` →
  mips fix + bpf_tracing LoongArch work present
- **[Phase 4]** `b4 am 20260526063936.16769-1-yangtiezhu@loongson.cn` →
  patch retrieved; 1 message, no replies
- **[Phase 4]** WebFetch lore.kernel.org → blocked (bot protection);
  used b4 mbox instead
- **[Phase 5]** `grep __loongarch__ tools/` — found in seccomp_bpf.c,
  bpf_tracing.h, etc., but NOT in bpf.c `__NR_bpf` block
- **[Phase 5]** Read `seccomp_bpf.c` lines 134–164 — `__NR_seccomp` for
  `__loongarch__` already defined
- **[Phase 6]** `grep __NR_bpf tools/lib/bpf/bpf.c` — no `__loongarch__`
  branch in 6.18.44
- **[Phase 6]** `include/uapi/asm-generic/unistd.h` line 677 → `#define
  __NR_bpf 280`
- **[Phase 6]** `tools/arch/loongarch/include/uapi/asm/unistd.h` →
  includes `asm-generic/unistd.h`
- **[Phase 6]** `arch/loongarch/` exists; `git log --reverse --
  arch/loongarch/ | head -1` → fa96b57c14906
- **[Phase 7]** `git log -20 -- arch/loongarch/` — active LoongArch
  development including BPF fixes
- **[Phase 8]** Assessed as build-time failure, platform-specific, low
  runtime risk

**YES**The background search finished. It confirmed that **"libbpf: Add
__NR_bpf definition for LoongArch" is not in the current 6.18.44
branch** — related LoongArch libbpf work is already there
(`bpf_tracing.h`, `PT_REGS_CAST`), but the `__NR_bpf` fallback in
`bpf.c` and `test-bpf.c` is still missing.

That matches the earlier analysis: this is a small, low-risk build fix
for LoongArch bpf tool compilation and should be backported to this
tree.

**YES**

 tools/build/feature/test-bpf.c | 2 ++
 tools/lib/bpf/bpf.c            | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
index e7a405f83af6e..89d59674f39b9 100644
--- a/tools/build/feature/test-bpf.c
+++ b/tools/build/feature/test-bpf.c
@@ -20,6 +20,8 @@
 #  define __NR_bpf 6319
 # elif defined(__mips__) && defined(_ABI64)
 #  define __NR_bpf 5315
+# elif defined(__loongarch__)
+#  define __NR_bpf 280
 # else
 #  error __NR_bpf not defined. libbpf does not support your arch.
 # endif
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 339b197972374..1e8f01bfc1bfd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -59,6 +59,8 @@
 #  define __NR_bpf 6319
 # elif defined(__mips__) && defined(_ABI64)
 #  define __NR_bpf 5315
+# elif defined(__loongarch__)
+#  define __NR_bpf 280
 # else
 #  error __NR_bpf not defined. libbpf does not support your arch.
 # endif
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] bpftool: Pass host flags to bootstrap libbpf

[Sasha Levin]

From: Leo Yan <leo.yan@arm.com>

[ Upstream commit 9080b97689dbf8d2c338a9af97cd2b4a714f25bf ]

bpftool builds a bootstrap libbpf with HOSTCC, but the libbpf submake can
still inherit target build flags through CFLAGS. This can break cross
builds when host objects are compiled with target-only options.

Since HOST_CFLAGS contains warning options that are not suitable for
building libbpf, use LIBBPF_BOOTSTRAP_CFLAGS with the warning options
removed to build the bootstrap libbpf. Clear EXTRA_CFLAGS so target
extra flags are not mixed into the host bootstrap libbpf build.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Acked-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/r/20260602-tools_build_fix_zero_init_bpf_only-v2-1-c76e5250ea1c@arm.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**

Record: `[bpftool] [Pass] Pass host flags to bootstrap libbpf — fix
bootstrap libbpf submake inheriting target build flags during cross-
compilation.`

**Step 1.2 — Tags**

| Tag | Value |
|-----|-------|
| Signed-off-by | Leo Yan \<leo.yan@arm.com\> |
| Acked-by | Quentin Monnet \<qmo@kernel.org\> (bpftool maintainer) |
| Link | https://lore.kernel.org/r/20260602-
tools_build_fix_zero_init_bpf_only-v2-1-c76e5250ea1c@arm.com |
| Signed-off-by | Alexei Starovoitov \<ast@kernel.org\> |

No Fixes:, Reported-by:, Tested-by:, or Cc: stable tags (expected for
manual review).

Record: Acked-by from bpf/bpftool maintainer. Part of `[PATCH bpf-next
v2 1/8]` series. No syzbot or user crash reports.

**Step 1.3 — Body analysis**

Record:
- **Bug:** bpftool builds bootstrap libbpf with `HOSTCC`, but the libbpf
  submake can still inherit target `CFLAGS`/`EXTRA_CFLAGS` from the
  parent make.
- **Symptom:** Cross-build failures when host objects are compiled with
  target-only compiler options.
- **Root cause:** Submake does not override inherited flags;
  `HOST_CFLAGS` warning options are also unsuitable for libbpf’s own
  warning setup.
- **Fix approach:** Pass `CFLAGS="$(LIBBPF_BOOTSTRAP_CFLAGS)"` (host
  flags with warnings stripped) and `EXTRA_CFLAGS=` to the bootstrap
  libbpf submake.

**Step 1.4 — Hidden bug fix?**

Record: No — this is an explicit build-system bug fix, not disguised
cleanup.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**

| File | Changes |
|------|---------|
| `tools/bpf/bpftool/Makefile` | +5 / -1 |

Functions/rules modified: `$(LIBBPF_BOOTSTRAP)` recipe, new
`LIBBPF_BOOTSTRAP_CFLAGS` variable.

Record: Single-file, surgical Makefile change. Scope: build-system only.

**Step 2.2 — Code flow change**

Hunk 1 — `$(LIBBPF_BOOTSTRAP)` recipe:
- **Before:** Submake invoked with `HOSTCC`/`HOSTLD`/`HOSTAR` and
  `ARCH=`/`CROSS_COMPILE=` cleared, but no explicit `CFLAGS` or
  `EXTRA_CFLAGS`.
- **After:** Submake gets explicit `CFLAGS="$(LIBBPF_BOOTSTRAP_CFLAGS)"`
  and `EXTRA_CFLAGS=`.

Hunk 2 — new variable:
- **Before:** No dedicated bootstrap libbpf CFLAGS.
- **After:** `LIBBPF_BOOTSTRAP_CFLAGS` = `HOST_CFLAGS` with `-W`,
  `-Wall`, `-Wextra`, `-Wformat`, `-Wformat-signedness` removed.

Record: Normal bootstrap libbpf build path during cross-compilation is
affected.

**Step 2.3 — Bug mechanism**

Record: **Build-system flag leakage.** Parent make exports/inherits
`CFLAGS` and `EXTRA_CFLAGS` into the libbpf submake.
`tools/lib/bpf/Makefile` uses `ifdef EXTRA_CFLAGS` to replace `CFLAGS`
entirely, and appends `$(CLANG_CROSS_FLAGS)`. Without explicit
overrides, target cross-compile flags reach host bootstrap objects.

**Step 2.4 — Fix quality**

Record: Fix is obviously correct, minimal, and follows the existing
pattern in `tools/bpf/resolve_btfids/Makefile` (`CROSS_COMPILE=""
CLANG_CROSS_FLAGS="" EXTRA_CFLAGS="$(HOSTCFLAGS)"`). Low regression risk
— Makefile-only, bootstrap path only.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**

Record: `$(LIBBPF_BOOTSTRAP)` recipe dates to 2020–2023
(`ced846c65e8ff`, `8859b0da5aac2`, `c62dd8a58d19f`, `af0e26beaa693c`).
Cross-build partial fixes: `bdadbb44c90ae` (2021, clang cross),
`0b817059a8830` (2022, `HOSTAR`), `cc9b22dfa7358` (2024, `HOST_CFLAGS`
cleanup). Buggy gap (no explicit CFLAGS/`EXTRA_CFLAGS=` for libbpf
submake) has existed since bootstrap libbpf was introduced.

**Step 3.2 — Fixes: tag**

Record: N/A — no Fixes: tag.

**Step 3.3 — Related file history**

Record: Related commits in this tree:
- `bdadbb44c90ae` — Enable cross-building with clang
- `0b817059a8830` — Fix bootstrapping during cross compilation (HOSTAR)
- `cc9b22dfa7358` — Clean up HOST_CFLAGS/HOST_LDFLAGS
- `8d86767be9c9b` — Add `-Wformat-signedness` (relevant to warning
  stripping)

On master, this commit is patch 1/8 of series
`tools_build_fix_zero_init_bpf_only`; patches 2–3 (`956841cbc3d77`,
`3f2fec5b02b6e`) further refine HOST_CFLAGS handling. Patches 4–8 touch
libbpf/selftests and are not prerequisites for this Makefile hunk.

**Step 3.4 — Author context**

Record: Leo Yan is an active Arm/tools contributor. Quentin Monnet
(bpftool maintainer) Acked-by.

**Step 3.5 — Dependencies**

Record: Commit applies cleanly to 6.18.44 (`git apply --check` passes).
Does not require `HOST_EXTRACFLAGS` (not present in this tree).
Standalone for the submake flag-leakage mechanism. Patch 2 from the same
series would improve completeness when `EXTRA_CFLAGS` contains target
flags (because in this tree `HOST_CFLAGS` is computed after
`EXTRA_CFLAGS` is appended to `CFLAGS`).

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**

Record: `b4 dig -c 9080b97689db` → https://patch.msgid.link/20260602-
tools_build_fix_zero_init_bpf_only-v2-1-c76e5250ea1c@arm.com. Lore page
blocked by bot protection; content verified via openwall mirror and
GitHub commit page.

**Step 4.2 — Reviewers**

Record: CC list includes bpf maintainers (Starovoitov, Borkmann,
Nakryiko, Monnet, etc.). Acked-by: Quentin Monnet.

**Step 4.3 — Bug report**

Record: No external bug report or syzbot link. Failure mode described in
commit message and series cover letter (cross-build breakage).

**Step 4.4 — Series context**

Record: Series `[PATCH bpf-next v2 0/8] tools build: bpf: Append
EXTRA_CFLAGS and HOST_EXTRACFLAGS`. Patch 1 was added in v2 specifically
to fix bootstrap libbpf cross-build flag leakage. Other patches address
GCC 15 zero-init and broader EXTRA_CFLAGS infrastructure.

**Step 4.5 — Stable list**

Record: UNVERIFIED — could not search lore stable list (bot protection).
No evidence this was previously rejected for stable.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions/rules**

Record: `$(LIBBPF_BOOTSTRAP)` make rule; `LIBBPF_BOOTSTRAP_CFLAGS`
variable definition.

**Step 5.2 — Callers**

Record: `$(LIBBPF_BOOTSTRAP)` is a dependency of bootstrap bpftool
objects (`$(BOOTSTRAP_OBJS)`, `$(BPFTOOL_BOOTSTRAP)`). Triggered during
bpftool feature detection requiring bootstrap (e.g. `clang-bpf-co-re`)
and during cross-compiled bpf tools builds (`tools/bpf/Makefile`,
selftests).

**Step 5.3 — Callees**

Record: Submake into `tools/lib/bpf/` with `HOSTCC`. libbpf Makefile
reads `EXTRA_CFLAGS`, `CFLAGS`, `CLANG_CROSS_FLAGS`.

**Step 5.4 — Reachability**

Record: Reachable when building bpf tools in-tree during cross-
compilation (`make tools/bpf` or full tools install with cross
`CC`/`CROSS_COMPILE`). Not a syscall/runtime path; build-time only.

**Step 5.5 — Similar patterns**

Record: `tools/bpf/resolve_btfids/Makefile` already uses
`HOST_OVERRIDES` with `CROSS_COMPILE="" CLANG_CROSS_FLAGS=""
EXTRA_CFLAGS="$(HOSTCFLAGS)"` — same class of fix, already in this tree.

---

## Phase 6: Cross-Reference Against Local Tree

**Step 6.1 — Buggy code present?**

Record: **YES.** Local tree is **Linux 6.18.44** (`git describe HEAD` →
`v6.18.44-1-g2736c32da98b9`). Current `tools/bpf/bpftool/Makefile` lines
47–50 invoke libbpf bootstrap submake without explicit `CFLAGS` or
`EXTRA_CFLAGS=`. Commit `9080b97689db` is on `master`/`bpf-next` but
**not** in this 6.18.y checkout.

**Step 6.2 — Backport complications**

Record: **Clean apply** — `git apply --check` succeeds with no
conflicts.

**Step 6.3 — Related fixes already present?**

Record: Prior cross-build fixes are present (`bdadbb44c90ae`,
`0b817059a8830`, `cc9b22dfa7358`), but none address libbpf submake
CFLAGS leakage. `LIBBPF_BOOTSTRAP_CFLAGS` not found in tree.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem**

Record: **tools/bpf/bpftool** — IMPORTANT for bpf tooling, PERIPHERAL
for kernel runtime.

**Step 7.2 — Activity**

Record: Actively maintained; recent Makefile changes in 6.18.y include
signing support, `-Wformat-signedness`, zstd linking.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**

Record: Users cross-compiling bpf tools (distro builders, embedded/ARM
developers). Does not affect already-built kernels or runtime behavior.

**Step 8.2 — Trigger conditions**

Record: Cross-compilation of bpftool with bootstrap libbpf build
(feature detection or explicit bootstrap target). Requires
`EXTRA_CFLAGS`/`CFLAGS` with target-specific options to leak. Common in
distro/SDK cross-build environments.

**Step 8.3 — Failure mode severity**

Record: **Compilation failure** during tools build — severity **MEDIUM**
(build breakage, not crash/corruption/security).

**Step 8.4 — Risk vs benefit**

| | Assessment |
|--|------------|
| Benefit | Prevents cross-build failures for bpftool; fills known gap
left by earlier cross-build fixes |
| Risk | Very low — 5-line Makefile change, bootstrap-only path |
| Ratio | Favorable for stable under build-fix exception |

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Real, reproducible cross-build bug in existing code
- Build-fix exception category (stable-kernel-rules.rst)
- Small, surgical, maintainer-acked fix
- Applies cleanly to 6.18.44
- Precedent: `0b817059a8830` (similar bpftool cross-bootstrap fix) is in
  6.18.y history
- Matches established pattern in `resolve_btfids/Makefile`

**Evidence AGAINST:**
- Tools-only; no kernel runtime impact
- Part of 8-patch series; patch 2 would further improve
  `HOST_CFLAGS`/`EXTRA_CFLAGS` separation
- Only affects cross-compilation build paths
- No user crash reports or security implications

**Unresolved:** Full lore review thread unavailable (bot protection).
Whether patch 2 should accompany this for maximum `EXTRA_CFLAGS`
correctness in 6.18.y.

### Stable Rules Checklist

| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — Acked-by maintainer;
follows existing resolve_btfids pattern |
| 2. Fixes real bug affecting users? | **PASS** — cross-build
compilation failure |
| 3. Important issue? | **PASS** (build-fix exception) — compilation
error, not crash/security |
| 4. Small and contained? | **PASS** — 5 lines, one file |
| 5. No new features/APIs? | **PASS** — Makefile build flags only |
| 6. Can apply to local tree? | **PASS** — clean apply verified |

**Exception category:** Build fix.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message and
  `git show 9080b97689db`
- [Phase 2] Diff analysis: 5 lines added, 1 removed in
  `tools/bpf/bpftool/Makefile`
- [Phase 3] `git blame` on lines 47–50: bootstrap recipe from 2020–2023
  commits
- [Phase 3] `git log --oneline master -- tools/bpf/bpftool/Makefile`:
  found series commits 9080b97, 956841c, 3f2fec5
- [Phase 3] `git show bdadbb44c90ae`, `0b817059a8830`, `cc9b22dfa7358`:
  prior cross-build fixes confirmed
- [Phase 3] `git apply --check` on 9080b97689db: **passes cleanly**
- [Phase 4] `b4 dig -c 9080b97689db`: lore URL found; full thread
  UNVERIFIED (bot block)
- [Phase 4] openwall mirror: confirmed patch content and series context
  (v2 1/8)
- [Phase 5] Read `tools/lib/bpf/Makefile` lines 73–87, 101:
  `EXTRA_CFLAGS`/`CLANG_CROSS_FLAGS` inheritance confirmed
- [Phase 5] Read `tools/bpf/resolve_btfids/Makefile` line 19–20:
  analogous HOST_OVERRIDES pattern confirmed
- [Phase 5] Read `tools/scripts/Makefile.include` lines 100–117:
  `CLANG_CROSS_FLAGS` added to `CFLAGS` when `CROSS_COMPILE` set
- [Phase 6] `git describe HEAD`: v6.18.44; `make kernelversion`: 6.18.44
- [Phase 6] `grep LIBBPF_BOOTSTRAP_CFLAGS`: not in tree (fix absent)
- [Phase 6] Read current `tools/bpf/bpftool/Makefile` lines 47–50,
  84–92: buggy code confirmed
- [Phase 6] `git cat-file -t 9080b97689db`: commit exists on master/bpf-
  next, not in current HEAD
- [Phase 7] `grep HOST_EXTRACFLAGS tools/`: not present (patch 3
  infrastructure absent)
- [Phase 8] `git log stable/linux-6.18.y --grep="cross" --
  tools/bpf/bpftool/Makefile`: `0b817059a8830` in stable history

This is a valid, low-risk build fix for a real cross-compilation failure
in bpftool that exists in Linux 6.18.44 and applies cleanly.

**YES**

 tools/bpf/bpftool/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index fd43e5ea63f38..4b6670bad86e7 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -47,7 +47,8 @@ $(LIBBPF_INTERNAL_HDRS): $(LIBBPF_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_HDRS_
 $(LIBBPF_BOOTSTRAP): $(wildcard $(BPF_DIR)/*.[ch] $(BPF_DIR)/Makefile) | $(LIBBPF_BOOTSTRAP_OUTPUT)
 	$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(LIBBPF_BOOTSTRAP_OUTPUT) \
 		DESTDIR=$(LIBBPF_BOOTSTRAP_DESTDIR:/=) prefix= \
-		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" $@ install_headers
+		ARCH= CROSS_COMPILE= CC="$(HOSTCC)" LD="$(HOSTLD)" AR="$(HOSTAR)" \
+		CFLAGS="$(LIBBPF_BOOTSTRAP_CFLAGS)" EXTRA_CFLAGS= $@ install_headers
 
 $(LIBBPF_BOOTSTRAP_INTERNAL_HDRS): $(LIBBPF_BOOTSTRAP_HDRS_DIR)/%.h: $(BPF_DIR)/%.h | $(LIBBPF_BOOTSTRAP_HDRS_DIR)
 	$(call QUIET_INSTALL, $@)
@@ -92,6 +93,9 @@ HOST_CFLAGS := $(subst -I$(LIBBPF_INCLUDE),-I$(LIBBPF_BOOTSTRAP_INCLUDE),\
 		$(subst $(CLANG_CROSS_FLAGS),,$(CFLAGS)))
 HOST_LDFLAGS := $(LDFLAGS)
 
+# Remove warnings for libbpf bootstrap build
+LIBBPF_BOOTSTRAP_CFLAGS := $(filter-out -W -Wall -Wextra -Wformat -Wformat-signedness,$(HOST_CFLAGS))
+
 INSTALL ?= install
 RM ?= rm -f
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] bpf, sockmap: reject a packet-modifying SK_SKB stream parser

[Sasha Levin]

From: Sechang Lim <rhkrqnwk98@gmail.com>

[ Upstream commit 31e2f36d3821811c03bddf5fd99ed8fc884fd222 ]

sk_psock_strp_parse() runs the BPF_PROG_TYPE_SK_SKB stream-parser program
to find the length of the next message. strparser assembles a message out
of several received skbs by chaining them onto the head's frag_list and
recording where to append the next one in strp->skb_nextp:

	*strp->skb_nextp = skb;
	strp->skb_nextp = &skb->next;

and then calls the parser on the head:

	len = (*strp->cb.parse_msg)(strp, head);

The parser is only meant to inspect the skb, but the program may call
bpf_skb_change_tail() -- or the sibling bpf_skb_pull_data(),
bpf_skb_change_head(), bpf_skb_adjust_room(), all allowed for SK_SKB.
Once the head carries a frag_list these go

	... -> skb_ensure_writable -> pskb_may_pull -> __pskb_pull_tail

and __pskb_pull_tail() frees the frag_list skbs that strparser still
tracks through skb_nextp:

	while ((list = skb_shinfo(skb)->frag_list) != insp) {
		skb_shinfo(skb)->frag_list = list->next;
		consume_skb(list);
	}

strp->skb_nextp now points into a freed sk_buff. The next segment of
the same message arrives in __strp_recv(), which links it with
*strp->skb_nextp = skb, an 8-byte write into the freed skb. The free
and the write happen in different __strp_recv() calls, so the message
has to span at least three segments before it triggers.

  BUG: KASAN: slab-use-after-free in __strp_recv+0x447/0xda0
  Write of size 8 at addr ffff88810db86140 by task repro/349

  Call Trace:
   <IRQ>
   __strp_recv+0x447/0xda0
   __tcp_read_sock+0x13d/0x590
   tcp_bpf_strp_read_sock+0x195/0x320
   strp_data_ready+0x267/0x340
   sk_psock_strp_data_ready+0x1ce/0x350
   tcp_data_queue+0x1364/0x2fd0
   tcp_rcv_established+0xe07/0x1640
   [...]

  Allocated by task 349:
   skb_clone+0x17b/0x210
   __strp_recv+0x2c3/0xda0
   __tcp_read_sock+0x13d/0x590
   [...]

  Freed by task 349:
   kmem_cache_free+0x150/0x570
   __pskb_pull_tail+0x57b/0xc20
   skb_ensure_writable+0x236/0x260
   __bpf_skb_change_tail+0x1d4/0x590
   sk_skb_change_tail+0x2a/0x40
   bpf_prog_1b285dcd6c41373e+0x27/0x30
   bpf_prog_run_pin_on_cpu+0xf3/0x260
   sk_psock_strp_parse+0x118/0x1e0
   __strp_recv+0x4f6/0xda0
   [...]

The same resize also leaves the head's length inconsistent with its
frags, so a later __pskb_pull_tail() can instead hit the
BUG_ON(skb_copy_bits(...)) in net/core/skbuff.c.

A stream parser is only meant to measure the next message, not to modify
the packet. Reject a parser whose program can change packet data
(prog->aux->changes_pkt_data) at attach time. The check is shared by
sock_map_prog_update() and sock_map_link_update_prog(), which between them
cover prog attach, link create and link update. Verdict programs are
unaffected and may still modify the skb.

Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
Link: https://lore.kernel.org/r/20260620024423.4141004-3-rhkrqnwk98@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The verification command finished: neither `git log --grep='packet-
modifying'` nor a search for `sock_map_prog_attach_check` returned any
commits. That confirms the fix is not in the **6.18.44** tree, which
aligns with the **YES** backport recommendation.

 net/core/sock_map.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 70bbc78fb079f..4ecc6cc6491fd 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -1517,6 +1517,17 @@ static int sock_map_prog_link_lookup(struct bpf_map *map, struct bpf_prog ***ppr
 	return 0;
 }
 
+static int sock_map_prog_attach_check(enum bpf_attach_type attach_type,
+				      struct bpf_prog *prog)
+{
+	/* A stream parser must not modify the skb, only measure it. */
+	if (prog && attach_type == BPF_SK_SKB_STREAM_PARSER &&
+	    prog->aux->changes_pkt_data)
+		return -EINVAL;
+
+	return 0;
+}
+
 /* Handle the following four cases:
  * prog_attach: prog != NULL, old == NULL, link == NULL
  * prog_detach: prog == NULL, old != NULL, link == NULL
@@ -1535,6 +1546,10 @@ static int sock_map_prog_update(struct bpf_map *map, struct bpf_prog *prog,
 	if (ret)
 		return ret;
 
+	ret = sock_map_prog_attach_check(which, prog);
+	if (ret)
+		return ret;
+
 	/* for prog_attach/prog_detach/link_attach, return error if a bpf_link
 	 * exists for that prog.
 	 */
@@ -1767,6 +1782,11 @@ static int sock_map_link_update_prog(struct bpf_link *link,
 		ret = -EINVAL;
 		goto out;
 	}
+
+	ret = sock_map_prog_attach_check(link->attach_type, prog);
+	if (ret)
+		goto out;
+
 	if (!sockmap_link->map) {
 		ret = -ENOLINK;
 		goto out;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] bpf: NUL-terminate replaced sysctl value

[Sasha Levin]

From: Dawei Feng <dawei.feng@seu.edu.cn>

[ Upstream commit a66e3b5bacf38d6ab29fa05a9754f7a114485605 ]

When writing to sysctls, proc_sys_call_handler() guarantees that the
buffer passed to proc handlers is NUL-terminated. If
bpf_sysctl_set_new_value() replaces the pending sysctl value, it can
hand a replacement buffer directly to proc handlers. However, the
helper currently copies only buf_len bytes into that buffer without
appending a NUL terminator, leaving downstream parsers vulnerable to
out-of-bounds access.

Fix this by appending a '\0' after the replaced value to restore the
expected sysctl semantics. Since the helper already rejects buf_len
greater than PAGE_SIZE - 1, there is always room for the extra byte.

Reproduced in a QEMU x86_64 guest booted with KASAN while exercising
the sysctl replacement path with a cgroup/sysctl BPF program. The
reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills
the original user write buffer with non-zero bytes, and overrides the
sysctl value so the replacement buffer lacks a terminating NUL. Under
that setup, the pre-fix kernel reported:

  BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90
  Read of size 1 at addr ffff88800de57000 by task repro_patch3/66
  CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x68/0xa0
   print_report+0xcb/0x5e0
   ? __virt_addr_valid+0x21d/0x3f0
   ? strnchrnul+0x72/0x90
   ? strnchrnul+0x72/0x90
   kasan_report+0xca/0x100
   ? strnchrnul+0x72/0x90
   strnchrnul+0x72/0x90
   bitmap_parse+0x37/0x2e0
   flow_limit_cpu_sysctl+0xc6/0x840
   ? __pfx_flow_limit_cpu_sysctl+0x10/0x10
   ? __kvmalloc_node_noprof+0x5ba/0x870
   proc_sys_call_handler+0x31d/0x480
   ? __pfx_proc_sys_call_handler+0x10/0x10
   ? selinux_file_permission+0x39f/0x500
   ? lock_is_held_type+0x9e/0x120
   vfs_write+0x98e/0x1000
   ...
   </TASK>
  The buggy address is located 0 bytes to the right of
  allocated 4096-byte region [ffff88800de56000, ffff88800de57000)
With this fix applied, rerunning the same sysctl-targeted path yields
no corresponding KASAN reports.

Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20260603105317.944304-2-dawei.feng@seu.edu.cn
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `bpf: NUL-terminate replaced sysctl value`

**Local tree:** Linux 6.18.44 (`git describe HEAD` → `v6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[bpf]` — fix (implicit via "NUL-terminate") — ensure BPF-
replaced sysctl write buffers are NUL-terminated before downstream proc
handlers parse them.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Zilin Guan, Dawei Feng, Alexei Starovoitov (ignore
  pipeline SOBs)
- **Acked-by:** Yonghong Song `<yonghong.song@linux.dev>` (BPF
  maintainer)
- **Link:** https://lore.kernel.org/r/20260603105317.944304-2-
  dawei.feng@seu.edu.cn
- No `Fixes:` tag (expected for manual review)
- No `Cc: stable@vger.kernel.org` in the committed message, but the v3
  series cover letter and sibling patches include stable CC (verified
  via b4 mbox)

**Notable patterns:** BPF maintainer ack; KASAN reproduction with full
stack trace; part of a 3-patch series fixing sysctl replacement path.

### Step 1.3: Body Analysis
**Record:**
- **Bug:** `bpf_sysctl_set_new_value()` copies `buf_len` bytes into
  `ctx->new_val` without appending `'\0'`, breaking the contract that
  `proc_sys_call_handler()` normally provides (NUL-terminated buffer).
- **Symptom:** KASAN slab-out-of-bounds in `strnchrnul` → `bitmap_parse`
  → `flow_limit_cpu_sysctl` when a cgroup/sysctl BPF program replaces a
  sysctl write value.
- **Root cause:** Downstream sysctl proc handlers (e.g. `cpumask_parse`
  → `bitmap_parse` with `UINT_MAX` length) scan until they find `'\0'`,
  reading past the valid string and past the kmalloc allocation.
- **Reproducer:** QEMU x86_64 + KASAN, BPF program targeting
  `/proc/sys/net/core/flow_limit_cpu_bitmap`.

### Step 1.4: Hidden Bug Fix?
**Record:** No — this is an explicit memory-safety bug fix (out-of-
bounds read), not disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `kernel/bpf/cgroup.c` (+1 line)
- **Function:** `bpf_sysctl_set_new_value()`
- **Scope:** Single-file, surgical fix (1 line added)

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `memcpy(ctx->new_val, buf, buf_len)` then set
  `ctx->new_len = buf_len` — buffer has no guaranteed terminator at
  `buf_len`.
- **After:** Same memcpy, then `((char *)ctx->new_val)[buf_len] = '\0'`
  — restores NUL-termination contract before
  `__cgroup_bpf_run_filter_sysctl()` hands the buffer to proc handlers
  via `proc_sys_call_handler()`.
- **Path affected:** Sysctl write path when a `BPF_CGROUP_SYSCTL`
  program calls `bpf_sysctl_set_new_value()`.

### Step 2.3: Bug Mechanism
**Record:** **Buffer overflow / out-of-bounds read (memory safety).**
`cpumask_parse()` calls `bitmap_parse(buf, UINT_MAX, ...)`, which calls
`strnchrnul(start, buflen, '\n')`. Without a NUL at the end of the
replaced string, `strnchrnul` keeps reading until it finds `'\0'`,
scanning past the kmalloc'd `PAGE_SIZE` buffer into unmapped memory.

### Step 2.4: Fix Quality
**Record:** Obviously correct and minimal. The helper already rejects
`buf_len > PAGE_SIZE - 1`, so index `buf_len` is always within the
`PAGE_SIZE` allocation. Matches what `proc_sys_call_handler()` does at
line 591 (`kbuf[count] = '\0'`). No regression risk — `ctx->new_len`
remains `buf_len` (length excluding terminator), consistent with normal
sysctl semantics.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Buggy `bpf_sysctl_set_new_value()` logic introduced in
`4e63acdff8646` ("bpf: Introduce bpf_sysctl_{get,set}_new_value
helpers", April 2019). All lines of the function blame to that commit.
Bug has existed since the helper was added.

### Step 3.2: Fixes Tag
**Record:** N/A — no `Fixes:` tag in commit message.

### Step 3.3: Related File History
**Record:** Recent related fixes already in this 6.18.44 tree:
- `d94ab0e91d3ff` — "bpf: Restore sysctl new-value from 1 to 0" (fixes
  stale `ret == 1` check; restores replacement functionality broken
  since `f10d05966196`)
- `65bd0c0afb0e1` — "bpf: use kvfree() for replaced sysctl write buffer"

These are patches 3/3 and 2/3 of the same v3 series. Only patch 1/3
(NUL-terminate) is missing from this tree.

### Step 3.4: Author Context
**Record:** Dawei Feng authored the full 3-patch sysctl series. Same
author committed patches 2 and 3 to this tree (via stable backports with
Greg KH as committer).

### Step 3.5: Dependencies
**Record:** Standalone one-line fix. The replacement path must be
functional for the bug to be reachable; `d94ab0e91d3ff` (already in
tree) restored that path. No additional prerequisites needed beyond
existing code.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260603105317.944304-2-dawei.feng@seu.edu.cn
- **Series revisions:** v1 (2026-05-26), v2 (2026-05-29), v3
  (2026-06-03) — committed version matches v3
- **Reviewer feedback:** Acked-by Yonghong Song; Reviewed-by Emil
  Tsalapatis, Jiayuan Chen; Acked-by Xu Kuohai
- **Stable nomination:** v3 cover letter and sibling patches CC
  `stable@vger.kernel.org`; reviewer noted "Without it the fix is
  unlikely to be picked up for stable"
- **No NAKs found** in mbox thread

### Step 4.2: Reviewers
**Record:** CC'd: ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, yonghong.song@linux.dev, bpf@vger.kernel.org, linux-
kernel@vger.kernel.org — appropriate BPF maintainers and lists.

### Step 4.3: Bug Report
**Record:** KASAN stack trace in commit message (self-contained
reproducer). No syzbot report. Reproduced by authors in QEMU with KASAN.

### Step 4.4: Series Context
**Record:** 3-patch series "bpf: fix sysctl new-value handling in
__cgroup_bpf_run_filter_sysctl()". Patches 2 and 3 already backported to
6.18.44; patch 1 is the remaining piece.

### Step 4.5: Stable List History
**Record:** Sibling patches in the series were explicitly CC'd to stable
and have already landed in this tree. This patch was intended for stable
as part of the same series.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `bpf_sysctl_set_new_value()` (modified); callers via BPF
helper dispatch in `sysctl_func_proto()`.

### Step 5.2: Callers / Impact Surface
**Record:** Called only from BPF programs attached as
`BPF_CGROUP_SYSCTL`. Triggered during `write()` to `/proc/sys/*` files
when `BPF_CGROUP_RUN_PROG_SYSCTL` runs in `proc_sys_call_handler()` →
`__cgroup_bpf_run_filter_sysctl()`.

### Step 5.3: Callees
**Record:** `memcpy()`, sets `ctx->new_updated`. On success,
`__cgroup_bpf_run_filter_sysctl()` replaces `*buf` with `ctx->new_val`
and calls the sysctl proc handler.

### Step 5.4: Reachability
**Record:**
```
write(/proc/sys/...) → proc_sys_write → proc_sys_call_handler
  → BPF_CGROUP_RUN_PROG_SYSCTL → __cgroup_bpf_run_filter_sysctl
    → bpf_prog_run (BPF program calls bpf_sysctl_set_new_value)
  → table->proc_handler (e.g. flow_limit_cpu_sysctl → cpumask_parse →
bitmap_parse → strnchrnul)
```
Reachable from syscall path (`write`). Requires privileges to load BPF
cgroup programs and write sysctls, but the OOB read is a real kernel
memory safety defect.

### Step 5.5: Similar Patterns
**Record:** `copy_sysctl_value()` in the same file correctly NUL-
terminates at lines 2332–2337. The missing NUL in
`bpf_sysctl_set_new_value()` is an inconsistency with established sysctl
helper semantics.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy Code Present?
**Record:** **YES.** Current `kernel/bpf/cgroup.c` lines 2386–2388 show
`memcpy` without NUL terminator:

```2386:2388:kernel/bpf/cgroup.c
        memcpy(ctx->new_val, buf, buf_len);
        ctx->new_len = buf_len;
        ctx->new_updated = 1;
```

Fix commit `a78e6d830b563` / upstream `a66e3b5bacf38` is **NOT** an
ancestor of HEAD.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — single line addition at a location
unchanged since 2019. No conflicts anticipated.

### Step 6.3: Related Fixes Already Present?
**Record:** Patches 2/3 and 3/3 of the series are already in tree
(`65bd0c0afb0e1`, `d94ab0e91d3ff`). No alternate fix for the NUL-
termination issue.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** `kernel/bpf/` — BPF cgroup sysctl filtering. **Criticality:
IMPORTANT** (core BPF infrastructure on sysctl write path; affects any
sysctl targeted by BPF programs).

### Step 7.2: Activity
**Record:** Actively maintained; recent sysctl-related fixes landed in
this tree in 2026.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** Systems using `BPF_PROG_TYPE_CGROUP_SYSCTL` programs that
call `bpf_sysctl_set_new_value()`. Config-dependent
(`CONFIG_BPF_SYSCALL`, `CONFIG_CGROUP_BPF`).

### Step 8.2: Trigger Conditions
**Record:** Sysctl write + BPF program replaces value via
`bpf_sysctl_set_new_value()` + downstream proc handler parses buffer as
C string. Requires elevated privileges (CAP_BPF, sysctl write access).
Replacement path is now functional in 6.18.44 after `d94ab0e91d3ff`.

### Step 8.3: Failure Mode Severity
**Record:** KASAN slab-out-of-bounds read in `strnchrnul`. **Severity:
HIGH** — kernel memory safety violation; potential info leak or crash
depending on what lies past the allocation. Proven with KASAN.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH — prevents OOB read on a real, tested code path;
  completes a partially-backported fix series
- **Risk:** VERY LOW — one line, mirrors existing
  `proc_sys_call_handler` behavior, room guaranteed by `PAGE_SIZE - 1`
  limit
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Real, KASAN-proven slab-out-of-bounds read
- Small (1 line), obviously correct fix
- Bug present in 6.18.44 since helper introduction (2019); now reachable
  after sibling fix `d94ab0e91d3ff`
- BPF maintainer Acked-by
- Series explicitly nominated for stable; patches 2/3 already in this
  tree
- Completes an incomplete stable backport of a 3-patch series

**AGAINST backport:**
- Requires privileged BPF + sysctl access to trigger (not unprivileged
  attack)
- No CVE assigned (minor concern)

**Unresolved:** None material to the decision.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — KASAN reproducer; maintainer
   ack
2. Fixes a real bug affecting users? **PASS** — OOB read on sysctl write
   path
3. Important issue? **PASS** — memory safety / potential crash (HIGH)
4. Small and contained? **PASS** — 1 line, 1 file
5. No new features or APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply expected

### Step 9.3: Exception Categories
**Record:** N/A (standard bug fix, not a quirk/DT/device-ID exception).

### Step 9.4: Decision Rationale
This is a clear memory-safety fix for a bug that exists in Linux
6.18.44. The replacement path is functional in this tree (thanks to
`d94ab0e91d3ff`), making the OOB read reachable. Two of three patches
from the same fix series are already backported; this is the missing
piece. The fix is trivial, proven, and low-risk.

---

## Verification

- [Phase 1] `git describe HEAD` → v6.18.44; parsed subject, tags, body
  from provided commit message
- [Phase 1] Acked-by Yonghong Song confirmed in commit message
- [Phase 2] Read `kernel/bpf/cgroup.c` lines 2377–2391 — buggy code
  confirmed (no NUL terminator)
- [Phase 2] `git diff a78e6d830b563^..a78e6d830b563` — exactly 1 line
  added
- [Phase 2] Read `fs/proc/proc_sysctl.c` lines 583–600 — `kbuf[count] =
  '\0'` confirms expected contract
- [Phase 2] Read `net/core/sysctl_net_core.c` lines 209–223 —
  `cpumask_parse(buffer, mask)` on write path
- [Phase 2] Read `include/linux/cpumask.h` line 977–979 —
  `bitmap_parse(buf, UINT_MAX, ...)`
- [Phase 2] Read `lib/bitmap-str.c` line 476 — `strnchrnul(start,
  buflen, '\n')`
- [Phase 2] Read `lib/string.c` lines 367–371 — `strnchrnul` scans until
  `*s == 0`
- [Phase 3] `git blame -L 2377,2391 kernel/bpf/cgroup.c` → all lines
  from `4e63acdff8646` (2019-04-12)
- [Phase 3] `git show 4e63acdff8646` — introduced
  `bpf_sysctl_set_new_value`
- [Phase 3] `git log --oneline -30 -- kernel/bpf/cgroup.c` — related
  fixes `d94ab0e91d3ff`, `65bd0c0afb0e1` present
- [Phase 3] `git merge-base --is-ancestor f10d05966196 HEAD` →
  BPF_PROG_RUN_ARRAY change in tree
- [Phase 3] `git merge-base --is-ancestor a78e6d830b563 HEAD` → fix NOT
  in tree
- [Phase 4] `b4 dig -c a78e6d830b563` → lore URL found
- [Phase 4] `b4 dig -c a78e6d830b563 -a` → v1/v2/v3 series; v3 is latest
- [Phase 4] `b4 dig -c a78e6d830b563 -w` → BPF maintainers CC'd
- [Phase 4] `b4 dig -c a78e6d830b563 -m /tmp/bpf_nul_thread.mbox` —
  stable CC, Acked-by, Reviewed-by confirmed
- [Phase 5] Read `kernel/bpf/cgroup.c` lines 1931–1988 —
  `__cgroup_bpf_run_filter_sysctl` buffer replacement path
- [Phase 5] Read `include/linux/bpf-cgroup.h` lines 366–370 —
  `BPF_CGROUP_RUN_PROG_SYSCTL` macro
- [Phase 6] Confirmed buggy code at lines 2386–2388 without fix
- [Phase 6] `git merge-base --is-ancestor 65bd0c0afb0e1 HEAD` → kvfree
  fix in tree
- [Phase 6] `git merge-base --is-ancestor d94ab0e91d3ff HEAD` → ret==0
  fix in tree
- [Phase 8] KASAN stack trace from commit message — slab OOB at
  PAGE_SIZE boundary

**YES**

 kernel/bpf/cgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index fc2f44b60a551..86475115ccad6 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -2384,6 +2384,7 @@ BPF_CALL_3(bpf_sysctl_set_new_value, struct bpf_sysctl_kern *, ctx,
 		return -E2BIG;
 
 	memcpy(ctx->new_val, buf, buf_len);
+	((char *)ctx->new_val)[buf_len] = '\0';
 	ctx->new_len = buf_len;
 	ctx->new_updated = 1;
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] bpf: NUL-terminate replaced sysctl value

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The original sysctl buffer is allocated with `kvzalloc()` but erroneously freed with `kfree()` during buffer replacement, leading to potential kernel panics.
- [High] The sysctl buffer replacement logic is completely broken because it relies on `ret == 1`, but the BPF execution engine returns 0 on success. Furthermore, a non-zero return aborts the sysctl write.
--

commit 499368353ad755feaab0984797529c1470873194
Author: Dawei Feng <dawei.feng@seu.edu.cn>

bpf: NUL-terminate replaced sysctl value

This commit ensures that BPF-replaced sysctl write buffers are
NUL-terminated before downstream proc handlers parse them. It appends
a '\0' to the buffer in bpf_sysctl_set_new_value() to prevent out-of-bounds
reads when parsing the modified sysctl values.

Link: https://lore.kernel.org/r/20260603105317.944304-2-dawei.feng@seu.edu.cn

> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 248f517d66d04..aed2f087cfc4e 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -2346,6 +2346,7 @@ BPF_CALL_3(bpf_sysctl_set_new_value, struct bpf_sysctl_kern *, ctx,
>  		return -E2BIG;
>  
>  	memcpy(ctx->new_val, buf, buf_len);
> +	((char *)ctx->new_val)[buf_len] = '\0';

[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing issue
in the sysctl replacement path that bpf_sysctl_set_new_value() relies on.

Is it possible that replacing the sysctl buffer leads to a kernel panic
due to mismatched allocation and free functions?

In fs/proc/proc_sysctl.c:proc_sys_call_handler(), the user buffer is
allocated using kvzalloc():

    kbuf = kvzalloc(count + 1, GFP_KERNEL);

Under memory pressure for allocations larger than PAGE_SIZE, this can fall
back to vmalloc().

However, if a BPF program successfully updates the sysctl value via
bpf_sysctl_set_new_value(), __cgroup_bpf_run_filter_sysctl() in 
kernel/bpf/cgroup.c frees the original user buffer using kfree():

    kfree(*buf);

Could freeing a vmalloc pointer with kfree() cause memory corruption or a
kernel panic in the slab allocator?


[Severity: High]
This is also a pre-existing issue, but the sysctl buffer replacement logic
appears to be functionally broken.

Can bpf_sysctl_set_new_value() ever successfully modify a sysctl value?

In kernel/bpf/cgroup.c:__cgroup_bpf_run_filter_sysctl(), the replacement
branch is only taken if the return value is exactly 1:

    if (ret == 1 && ctx.new_updated) {

But the BPF execution engine in bpf_prog_run_array_cg() normally returns 0
on success, making the replacement branch unreachable:

    if (!func_ret && !IS_ERR_VALUE((long)run_ctx.retval))
        run_ctx.retval = -EPERM;

If a BPF program uses bpf_set_retval(1) to force a return value of 1,
__cgroup_bpf_run_filter_sysctl() will bubble up 1 as an error to
fs/proc/proc_sysctl.c:proc_sys_call_handler():

    if (error)
        goto out_free_buf;

Does this abort the sysctl write and skip calling the downstream
table->proc_handler, entirely breaking the replacement functionality?

>  	ctx->new_len = buf_len;
>  	ctx->new_updated = 1;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-556-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18] selftests/bpf: Avoid static LLVM linking for cross builds

[Sasha Levin]

From: Leo Yan <leo.yan@arm.com>

[ Upstream commit 62617d28d9ae123c0d6ba51035caa3ca52b94f7a ]

The BPF selftests prefer static LLVM linking, which works for native
builds but can break cross builds. Its --link-static output may include
host-only libraries that are unavailable for the cross compilation,
causing link failures.

Avoid static LLVM linking for cross builds and use shared LLVM libraries
instead. Native builds keep the existing behavior.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Link: https://lore.kernel.org/r/20260602-tools_build_fix_zero_init_bpf_only-v2-8-c76e5250ea1c@arm.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[selftests/bpf]` `[avoid]` — Avoid static LLVM linking for
cross builds. Subsystem is BPF selftest build infrastructure; action is
a preventive build fix.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Leo Yan `<leo.yan@arm.com>` (author)
- **Link:** https://lore.kernel.org/r/20260602-
  tools_build_fix_zero_init_bpf_only-v2-8-c76e5250ea1c@arm.com
- **Signed-off-by:** Alexei Starovoitov `<ast@kernel.org>` (BPF
  maintainer merge)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable in commit message
- Notable: part of bpf-next v2 series patch 8/8; no syzbot or user bug
  reports

### Step 1.3: Body Analysis
**Record:**
- **Bug:** BPF selftests prefer static LLVM linking via `llvm-config
  --link-static`; on cross builds this can pull in host-only libraries
  unavailable to the target linker, causing link failures.
- **Symptom:** Cross-compiled BPF selftest binaries fail to link.
- **Fix:** Use shared LLVM libraries when `ARCH != HOSTARCH`; native
  builds keep static-first behavior.
- **Root cause:** Static linking logic added without distinguishing
  native vs cross builds.

### Step 1.4: Hidden Bug Fix?
**Record:** No — this is an explicit build/link fix, not disguised
cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `tools/testing/selftests/bpf/Makefile` (+7 / -2 lines)
- **Scope:** Single-file, surgical Makefile change
- **Area:** LLVM library selection block (lines ~185–192)

### Step 2.2: Code Flow Change
**Record:**
- **Before:** Always probe `llvm-config --link-static`; if available,
  use static libs for all builds.
- **After:** If `ARCH != HOSTARCH`, skip static probe
  (`LLVM_LINK_STATIC` empty) and fall through to `--link-shared`. On
  native builds (`ARCH == HOSTARCH`), probe static linking as before.
- **Path affected:** Cross-compilation of LLVM-enabled BPF selftests
  only.

### Step 2.3: Bug Mechanism
**Record:** **Build fix / logic correctness.** Static LLVM link flags
reference host libraries unsuitable for cross-linking. Forcing shared
libs on cross builds avoids unresolved host dependencies.

### Step 2.4: Fix Quality
**Record:** Fix is small and follows the existing `ARCH`/`HOSTARCH`
pattern used in `tools/perf/Makefile.config`. Low regression risk on
cross builds. Minor edge case: unnormalized `ARCH=x86_64` vs normalized
`HOSTARCH=x86` on native builds could force shared instead of static
linking (degraded preference, not a breakage). Sashiko AI review flagged
this; committed version unchanged.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- Static-linking preference introduced by `67ab80a01886` (Sep 2024,
  Eduard Zingerman)
- Dynamic fallback added by `2a9d30fac818f` (Jan 2025, Daniel Xu)
- Shell redirection fix by `caa4237a790a9` (Mar 2025, Anton Protopopov)
- All three commits are present in this tree; buggy cross-build behavior
  dates to static-linking introduction

### Step 3.2: Fixes: Tag
**Record:** No Fixes: tag. N/A.

### Step 3.3: Related History
**Record:** Related stable-tree commits in same Makefile:
- `caa4237a790a9` — Fix selection of static vs dynamic LLVM (already in
  6.18.y)
- `cb3ade567816a` — Fix runqslower cross-endian build
- `fd526e121c4d6` — Fix cross-compiling urandom_read
- `3b796d3f16c10` — Allow selftests to build with older xxd
- Candidate commit `62617d28d9ae1` is **not** in this tree

### Step 3.4: Author Context
**Record:** Leo Yan is an active ARM/tools contributor (perf, kselftest,
bpf selftests). This patch is standalone within the broader tools-build
series.

### Step 3.5: Dependencies
**Record:** Patch 8/8 of v2 series, but this hunk is self-contained — no
dependency on earlier series patches for the LLVM linking logic. `git
apply --check` succeeds on current tree.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:**
- **URL:** https://patch.msgid.link/20260602-
  tools_build_fix_zero_init_bpf_only-v2-8-c76e5250ea1c@arm.com
- **Series:** v1 (6 patches, Mar 2026) → v2 bpf-next (8 patches, Jun
  2026); committed version is v2/8
- **Review feedback:** Sashiko AI flagged medium-severity concern about
  `ARCH` vs `HOSTARCH` normalization; suggested `SRCARCH` or
  `CROSS_COMPILE` check instead
- No stable nominations found in thread
- No NAKs; bpf maintainers CC'd

### Step 4.2: Reviewers
**Record:** CC'd bpf maintainers (Starovoitov, Borkmann, Nakryiko,
etc.), Shuah Khan (kselftest), llvm@lists.linux.dev. Series patches
received Acked-by from Quentin Monnet and Ihor Solodrai (other patches
in series, not specifically this one in commit message).

### Step 4.3: Bug Reports
**Record:** No external bug report, syzbot, or user Reported-by. Issue
inferred from cross-build failure mechanism.

### Step 4.4: Series Context
**Record:** v2/0 covers EXTRA_CFLAGS/HOST_EXTRACFLAGS append fixes;
patch 8/8 is independent for LLVM linking purposes.

### Step 4.5: Stable List
**Record:** No stable-specific discussion found for this patch.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions/Variables
**Record:** `LLVM_LINK_STATIC`, `LLVM_LDLIBS`, `LLVM_LDFLAGS` in
Makefile LLVM feature block.

### Step 5.2: Callers/Usage
**Record:** `LLVM_LDLIBS` used at line 707 in the link rule for selftest
binaries (e.g. `test_progs`). Only affects builds with `feature-llvm=1`
and `SKIP_LLVM!=1`.

### Step 5.3: Callees
**Record:** Invokes `llvm-config --link-static/--link-shared
--libs/--system-libs`.

### Step 5.4: Reachability
**Record:** Triggered when a developer/CI cross-compiles BPF selftests
with LLVM support (`make -C tools/testing/selftests/bpf` with
`ARCH!=host`). Not reachable from normal kernel runtime or typical
distro kernel packages. Userspace-triggerable: no.

### Step 5.5: Similar Patterns
**Record:** `tools/perf/Makefile.config` uses identical `ifeq ($(ARCH),
$(HOSTARCH))` for native vs cross detection. Makefile already uses
`ifneq ($(CROSS_COMPILE),)` elsewhere for cross-build handling.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **v6.18.44** (`linux-6.18.y`). Lines
185–192 still unconditionally prefer static LLVM linking. Introducing
commit `67ab80a01886` is an ancestor of HEAD.

### Step 6.2: Backport Complications
**Record:** **Clean apply** — `git apply --check` on commit
`62617d28d9ae1` succeeds with no conflicts.

### Step 6.3: Related Fixes Already Present?
**Record:** `caa4237a790a9` (shell redirection for static/dynamic probe)
is present. The cross-build guard from `62617d28d9ae1` is **not**
present.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem
**Record:** `tools/testing/selftests/bpf` — developer test
infrastructure. **Criticality: PERIPHERAL** (not core kernel runtime).

### Step 7.2: Activity
**Record:** Actively maintained; multiple bpf selftest build fixes
landed in 6.18.y (e.g. `3b796d3f16c10`, `4b65d5ae97143`,
`e860a98c8aebd`).

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Developers and CI systems cross-compiling BPF selftests with
LLVM on **6.18.y**. Not production kernel users.

### Step 8.2: Trigger Conditions
**Record:** Cross-compile (`ARCH != HOSTARCH`) + LLVM feature enabled +
static LLVM libs available on host. Uncommon but real for ARM/embedded
BPF development workflows.

### Step 8.3: Failure Mode
**Record:** **Link failure** during selftest build. **Severity: LOW** —
blocks optional test tooling, not kernel boot or data integrity.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** LOW-MEDIUM — restores cross-build of BPF selftests;
  aligns with prior stable backports of bpf cross-build fixes
- **Risk:** VERY LOW — 7-line Makefile change, cross-build path only
- **Ratio:** Modest benefit, very low risk; fits established 6.18.y
  precedent for bpf selftest build fixes

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real, reproducible cross-build link failure
- Small, obviously correct build fix
- Applies cleanly to 6.18.44
- Bug introduced by commit already in this tree
- Precedent in 6.18.y: `cb3ade567816a`, `fd526e121c4d6`,
  `caa4237a790a9`, other bpf selftest build fixes
- Build-fix exception category per stable rules
- Standalone patch, no series dependencies

**AGAINST backport:**
- Affects only optional selftest tooling, not kernel runtime
- No user reports, syzbot, or security impact
- "Important issue" bar is borderline — link failure in tests, not
  crash/corruption
- Minor edge case in ARCH/HOSTARCH comparison on native x86_64 builds

**Unresolved:** Whether Leo Yan addressed the Sashiko AI ARCH-
normalization concern in a follow-up (not in this commit).

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — logic is sound; merged by
   BPF maintainer; no functional regression on cross path
2. Fixes a real bug? **PASS** — cross-build link failures are real
3. Important issue? **PASS (borderline)** — build-fix exception; low
   severity but blocks a legitimate developer workflow; consistent with
   prior bpf selftest cross-build backports in this tree
4. Small and contained? **PASS** — 7 lines, one file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified

### Step 9.3: Exception Category
**Record:** **Build fix** for test infrastructure.

### Step 9.4: Decision Rationale

This tree (6.18.44) contains the static LLVM linking preference without
a cross-build guard, so the bug is real and reachable for cross-
compiling developers. The fix is minimal, applies cleanly, and matches
established 6.18.y practice of backporting BPF selftest build
fixes—including prior cross-compile fixes in the same Makefile. Impact
is limited to test tooling rather than production kernels, but stable
trees routinely carry such fixes to keep selftest CI and developer
workflows functional on stable branches.

---

## Verification

- [Phase 1] Parsed commit `62617d28d9ae1` message and tags from `git
  show`
- [Phase 2] Diff analysis: 1 file, +7/-2, LLVM linking block only
- [Phase 3] `git blame` lines 185–192: static linking from
  `67ab80a01886`, probe fix from `caa4237a790a9`
- [Phase 3] `67ab80a01886` is ancestor of HEAD; `62617d28d9ae1` is not
- [Phase 3] `git apply --check` on patch: succeeds
- [Phase 3] Related stable history: `cb3ade567816a`, `fd526e121c4d6`,
  `caa4237a790a9` in `stable/linux-6.18.y`
- [Phase 4] `b4 dig -c 62617d28d9ae1`: found lore thread
- [Phase 4] `b4 dig -a`: v1→v2 series, patch 8/8
- [Phase 4] `b4 dig -w`: BPF maintainers CC'd
- [Phase 4] Mbox review: Sashiko AI medium concern on ARCH/HOSTARCH
  normalization
- [Phase 4] No stable@vger nomination found in thread
- [Phase 5] `LLVM_LDLIBS` used at Makefile line 707 for selftest linking
- [Phase 5] `ARCH`/`HOSTARCH` defined in `tools/scripts/Makefile.arch`
  (included line 3)
- [Phase 6] `git describe HEAD`: v6.18.44-1-g2736c32da98b9; `make
  kernelversion`: 6.18.44
- [Phase 6] Buggy code confirmed at Makefile lines 185–192
- [Phase 6] Patch applies cleanly to current tree
- [Phase 7] Subsystem: bpf selftests (peripheral)
- [Phase 8] Failure mode: link error on cross-build; severity LOW; no
  runtime/security impact

**YES**

 tools/testing/selftests/bpf/Makefile | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 591e7e77f89ba..372ae53ae63ae 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -182,8 +182,15 @@ ifeq ($(feature-llvm),1)
   LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
   # both llvm-config and lib.mk add -D_GNU_SOURCE, which ends up as conflict
   LLVM_CFLAGS  += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
-  # Prefer linking statically if it's available, otherwise fallback to shared
-  ifeq ($(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo static),static)
+  # Cross compilation must use dynamic linking to avoid unresolved library
+  # dependencies. For native build, prefer linking statically if it's
+  # available, otherwise fallback to shared.
+  ifneq ($(ARCH), $(HOSTARCH))
+    LLVM_LINK_STATIC :=
+  else
+    LLVM_LINK_STATIC := $(shell $(LLVM_CONFIG) --link-static --libs >/dev/null 2>&1 && echo y)
+  endif
+  ifeq ($(LLVM_LINK_STATIC),y)
     LLVM_LDLIBS  += $(shell $(LLVM_CONFIG) --link-static --libs $(LLVM_CONFIG_LIB_COMPONENTS))
     LLVM_LDLIBS  += $(filter-out -lxml2,$(shell $(LLVM_CONFIG) --link-static --system-libs $(LLVM_CONFIG_LIB_COMPONENTS)))
     LLVM_LDLIBS  += -lstdc++
-- 
2.53.0