os/v3/puppy: the image builds amdxdna from pin 526c6081, which predates the bo_invalid_list fix, so the next stick ships the panicking module #971

The owner installed the fixed amdxdna on the box on 2026-11-04 ~03:0x (bo_invalid_list use-after-free, patch 5/5). The image does not get that fix, so the next stick (c22) would carry the same module that panicked the box at 01:48 — and a board boot is exactly the exposure the maintenance was for.

The chain, measured, not inferred

1. os/v3/puppy/README.md ("kernel bump" step 2): the image ships amdxdna 0.18.0, from third_party/xdna-driver's pin.
2. .gitmodules → https://github.com/amd/xdna-driver.git; the engine tree pins 526c6081974ea4f0f7dd22329186c5d6adb8fad5 ("accel/amdxdna: honour a user-requested partition start column").
3. ~/wt/xdna-crash-fix/src — the scratch tree the rule names — is checked out at exactly that pin, and the fix exists there as uncommitted working-tree changes:

 drivers/accel/amdxdna/amdxdna_drm.c  | 12 ++++++++++++
 drivers/accel/amdxdna/amdxdna_gem.c  | 18 ++++++++++++++++--
 drivers/accel/amdxdna/amdxdna_ubuf.c | 10 ++++++++++
 3 files changed, 38 insertions(+), 2 deletions(-)

with list_del_init(&abo->node) on the two paths that free a BO while it is still linked in client->bo_invalid_list.

So the pin is pre-fix: nothing upstream of it, and the image build has no patch step, so updates/amdxdna.ko in the zdrv is the unfixed driver. g3-probe.sh cannot catch this today — it asserts presence, vermagic and signer, none of which say anything about which source the module came from.

Why this is this lane's problem

The stick is the deliverable and the board boot is the gate; a stick that ships a driver with a known use-after-free turns a board run into a potential panic — the same one that took the box down with kernel BUG at lib/list_debug.c:32 in amdxdna_hmm_invalidate.

Two ways to fix it, and the choice is the owner's

• A. carry the patch in the image build (what the box itself is running now): commit the 3-file diff as os/v3/puppy/patches/amdxdna-bo-invalid-list.patch, apply it in the module build, and refuse to publish an image whose module tree came from an unpatched source (a marker check at build time, since the built .ko cannot be asked).
• B. bump the pin to a source that contains the fix, once AMD carries it, and let g3-probe.sh assert the pin rather than the file.

Both need the same new gate: build-time provenance, not just signer/vermagic. Which one is wanted is the owner's call — it is a decision about shipping a local patch vs. waiting for upstream, and it interacts with the follow-up race fix the rule says is still coming (a patch carried now has to be dropped when that lands).

I am not patching, pinning or building anything until that is decided: no module is installed or loaded by this lane, per the operator rule.