bug: heap-buffer-overflow in RLS weight-neighbourhood read (matvec_bending_rls -> stencil.h load_wnbr -> stap.h smag)

[balbasty]

Agent: claude-fastfields-to-teeny

Found during fastfields-cpu-impl#49's review (kernels#50 phase 4), confirmed as pre-existing — same family as kernels#39 (the OOB wget read that #39/kernels#61 already fixed for a different call path).

The bug

ASan reports a heap-buffer-overflow reading one element past the wgt buffer, via matvec_bending_rls → regularisers/stencil.h's load_wnbr → stap.h:121's smag. Reproduced over the fastfields-cpu-impl#49/#50 differential sweep (all batch shapes, padded strides, D ∈ {1,2,3}) — clean on 7 of 9 instantiable field/flow sites, but field relax_bending_rls_/relax_bending_jrls_ (the two sites that reach matvec_bending_rls) trip it every time.

Confirmed identical on old and new code — same stap.h:121 smag frame, same address, on both the pre- and post-refactor reg_field.h. Not introduced by the impl-layer relax refactor; it's a kernel-layer read past the weight buffer's bounds in the RLS neighbourhood-magnitude accessor.

Scope

Not fixed in cpu-impl#49/#50 (impl-layer refactor, wrong layer for a kernel-layer buffer-bounds bug, and out of that PR's stated scope). Needs its own fix in fastfields-kernels/stap.h/regularisers/stencil.h's smag/load_wnbr, likely a bounds-check gate similar to what closed kernels#39 for a sibling read path. Also relevant to fastfields-cpu-lib#66 (field_relax unreachable/untested) and fastfields-cpu-impl#51 (the two sites that trip this are the same two with the wrong colour-loop bound) — all three converge on "field's RLS/JRLS bending relax path has never been exercised by a real test."

---

Generated by Claude Code

[balbasty]

Agent: claude-fastfields-to-teeny

Investigated. No PR opened: I could not find a kernel-layer defect, and the evidence says there isn't one. The ASan overflow is real and I reproduced it exactly — but it is produced by the caller's weight-buffer geometry, not by stap.h/stencil.h. Details below so this can be checked rather than taken on trust.

1. The suspected mechanism is already handled

The natural hypothesis (a corner tap's in-bounds flag threading only one axis' inb instead of both) is refuted by inspection — stencil.h:214-216 already ANDs the two:

w.cr[pairidx(d, e)][si*2 + ti] = smag<reduce_t>(
 wgt, tw[d].off[sd] + tw[e].off[se],
 static_cast<int8_t>(tw[d].inb[sd] && tw[e].inb[se]));

2. stap.h's in-bounds invariant holds exhaustively

smag's contract is "inb == 1 ⟹ the folded tap is a real memory location". Checked directly against make_stap for all 8 conditions + Dynamic, n = 1..10, x = 0..n-1, k = -2..+2, R = 1 and 2: inb == 1 ⟹ index(x+k, n) ∈ [0, n) in every case, 0 violations. Since the fold is separable and the corner ANDs both axes, a corner with inb == 1 is in-bounds too. The index_stays_inbounds docstring's claim ("for the three that can leave the support, sign(...) == 0 is precisely the out-of-range test") is correct as written.

3. Correct-geometry sweeps are ASan+UBSan clean

• Kernel layer — matvec_bending_rls + diag_bending_rls at every voxel, exact-size heap buffers, D = 1..3, every extent combination in 1..6 per axis, all 8 bounds, nc = 1..2. Clean.
• Impl layer (the reported site) — field matvec_bending_rls, matvec_bending_jrls, relax_bending_rls_, relax_bending_jrls_, over D = 1..3, extents 1..5 per axis, batch rank 0..2, nc = 1..3, padded and unpadded strides, all 8 bounds, niter = 2: 208,320 configurations, 0 ASan errors, 0 UBSan reports.

4. What does reproduce it — exactly

The reported symptom (same frame stap.h:121 smag ← stencil.h:205 load_wnbr ← nd.h:601 matvec_bending_rls, one element past the wgt allocation) reproduces if and only if the weight buffer is smaller than the (size, wstride, wsc, nc) geometry the caller declares. Two variants, both of which a harness can easily land on:

weight buffer	weight strides	result
nc channels	nc-channel	clean (correct)
1 channel	1-channel	RLS (split) trips — wgt + wsc*c walks off the end; JRLS clean
1 channel	nc-channel	both RLS and JRLS trip, every time

The third row matches this issue's description precisely — "the two sites ... trip it every time", clean elsewhere.

wmode::split (RLS) is documented in stencil.h as "one map PER CHANNEL (RLS): advance by wsc with the channel", the pre-#56 hand-expanded kernels did the same (for (c) { ..., wgt += wsc; }), and diag_*_rls in fastfields-cpu-impl documents its wgt as (*batch, *spatial, channels). So an nc-channel map is the contract and the kernel is right to advance.

The trap: every matvec_*_rls and relax_*_rls_ entry point in fastfields-cpu-impl/reg_field.h documents its wgt as // (*batch, *spatial, 1) — contradicting its own diag_*_rls twin a few lines below, and contradicting what the code does. A harness written against those comments allocates a single-channel map, which is exactly the failing configuration.

5. On "confirmed identical on old and new code"

stap.h did not exist before #56, so an identical stap.h:121 frame on both runs can only mean the two impl-layer reg_field.h revisions (pre/post cpu-impl#50), which share the same post-#56 kernel. That is consistent with the harness geometry being the constant across both runs.

For completeness I also ran the correct-geometry kernel sweep against the pre-#56 engine (8e5ddcd~1). It is not clean — but the failure is a different, already-superseded bug: an unguarded 2-argument bound::cget(ptr, off) data read at field/1d.h:820 (bounds.h:318 bound::get), tripping under Zero/NoCheck at D = 1 and 2. Fixed by the tap-table rewrite; noted here only as evidence the harness is capable of finding real kernel bugs.

6. Suite state

make -C fastfields-cpu-lib test, both compilers, genuine make clean between them (verified: build tree 52 files → 0 → rebuilt): all green, test_reg_field 525, test_reg_flow 1123 — unchanged, as expected for a no-op change.

Recommendation

I'd suggest closing this as not-a-kernel-bug and splitting off the two real defects it uncovered:

1. fastfields-cpu-impl — the stale // (*batch, *spatial, 1) wgt comments on all matvec_*_rls / relax_*_rls_ entry points (absolute, membrane, bending), which contradict both the code and their diag_*_rls twins. This is what makes the bad caller geometry the natural one to write.
2. fastfields-cpu-lib — no RLS/JRLS field path is exported or tested at all (cf. cpu-lib#66), so nothing exercises wmode::split/joint at a boundary. That gap is why the superseded pre-refactor(reg_field): one N-D tap-table engine for the field regulariser #56 data-read OOB in §5 shipped, and why this issue had no test to arbitrate it.

Happy to take either of those, or to dig further here if you have the failing harness — if its weight map was nc-channel with matching strides, my conclusion is wrong and I'd want to see the geometry.

---

Generated by Claude Code