diff --git a/build/buildroot-2025.02.8.tar.xz.sha256 b/build/buildroot-2025.02.8.tar.xz.sha256
new file mode 100644
index 0000000..ee8865d
--- /dev/null
+++ b/build/buildroot-2025.02.8.tar.xz.sha256
@@ -0,0 +1 @@
+695360d10d038122f11c76c35f3bd10561d949af2bc90468659f4ec5ee6687cc  buildroot-2025.02.8.tar.xz
diff --git a/build/fetch-buildroot-tarball.sh b/build/fetch-buildroot-tarball.sh
new file mode 100755
index 0000000..84a0b31
--- /dev/null
+++ b/build/fetch-buildroot-tarball.sh
@@ -0,0 +1,54 @@
+#!/usr/bin/env bash
+# Fetch (with retries) and sha256-verify the pristine Buildroot tarball into $1.
+#
+# WHY THIS EXISTS. The firmware builds against
+# sysdrv/source/buildroot/buildroot-2025.02.8 inside the vendor SDK. That tree
+# is NOT in the vendor checkout -- the SDK ships 2023.02.6 -- and nothing
+# recorded where it came from, so the build was reproducible only on the one
+# machine that happened to have the directory (flare-edge#135). Buildroot signs
+# its releases with GPG rather than publishing a .sha256, so the pin here was
+# computed from the downloaded tarball and is what this script verifies against.
+#
+# Same shape as fetch-kernel-tarball.sh, deliberately: a version bump edits this
+# file and the pin beside it, nothing else. FAILS CLOSED on a missing pin.
+#
+# Usage: fetch-buildroot-tarball.sh <destination-path>
+set -euo pipefail
+
+BRVER=2025.02.8
+HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"     # build/
+SHA_FILE="$HERE/buildroot-$BRVER.tar.xz.sha256"
+URL="https://buildroot.org/downloads/buildroot-$BRVER.tar.xz"
+
+TB="${1:?usage: fetch-buildroot-tarball.sh <destination-path>}"
+
+[ -f "$SHA_FILE" ] || {
+  echo "FATAL: no pinned sha256 for buildroot-$BRVER (expected $SHA_FILE):" >&2
+  echo "       refusing an unverified tarball" >&2
+  exit 1
+}
+WANT="$(awk '{print $1; exit}' "$SHA_FILE")"
+
+verify() {
+  [ -f "$TB" ] || return 1
+  local got
+  got="$(sha256sum "$TB" | awk '{print $1}')"
+  [ "$got" = "$WANT" ]
+}
+
+if verify; then
+  echo "buildroot-$BRVER: already present and verified"
+  exit 0
+fi
+
+for attempt in 1 2 3; do
+  echo "== fetching buildroot-$BRVER (attempt $attempt)"
+  if curl -fsSL --retry 2 -o "$TB" "$URL" && verify; then
+    echo "buildroot-$BRVER: sha256 verified"
+    exit 0
+  fi
+  rm -f "$TB"
+done
+
+echo "FATAL: could not fetch a buildroot-$BRVER tarball matching $WANT" >&2
+exit 1
diff --git a/build/vendor.manifest b/build/vendor.manifest
index 59a9694..a9b957a 100644
--- a/build/vendor.manifest
+++ b/build/vendor.manifest
@@ -12,6 +12,21 @@
 # and fetch-vendor.sh is the only thing that acts on it. A checkout that has
 # drifted off its pin is reported, never silently used.
 #
+# NOT EVERYTHING HERE IS A GIT TREE. Two build inputs are pinned tarballs
+# instead, each with its own fetch-and-verify script beside this file, because a
+# release tarball has no commit to name:
+#
+#   linux-6.18.46        build/fetch-kernel-tarball.sh
+#   buildroot-2025.02.8  build/fetch-buildroot-tarball.sh
+#
+# The buildroot one matters more than it looks. The firmware builds against
+# sysdrv/source/buildroot/buildroot-2025.02.8 inside the vendor SDK, and the
+# vendor SDK ships 2023.02.6 -- so that tree is not in the vendor checkout, was
+# not in this manifest, and had no recorded origin at all. A clean rebuild
+# silently used the vendor's older buildroot and produced a different userspace
+# (flare-edge#135). Our delta on top of it is captured in the flare-edge repo at
+# sdk-patches/buildroot/.
+#
 # Format: name<TAB>url<TAB>commit<TAB>description
 # Blank lines and lines starting with '#' are ignored.