Unaligned safetensors reads need a checker: three recurrences found by UBSan, and one site UBSan cannot see

[localai-bot]

UBSan on the sanitize-cpu (address,undefined) CI leg:

src/vllm/model_executor/models/qwen3_5_weights.cpp:298:36: runtime error:
load of misaligned address 0x7f00df8027db for type const uint16_t,
which requires 2 byte alignment

TransposeBf16 (qwen3_5_weights.cpp:293-301) takes a const uint16_t* and dereferences it directly. One of its two callers, :334, produces that pointer by reinterpret_cast<const uint16_t*>(t.data), where t.data points into the mmapd safetensors buffer:

TransposeBf16(reinterpret_cast<const uint16_t*>(t.data), out_dim, in_dim,
              reinterpret_cast<uint16_t*>(o.bytes.data()));

Safetensors provides no alignment guarantee for tensor data offsets. They are byte offsets into a contiguous data block, determined by the sizes of preceding tensors — so a bf16 tensor that follows an odd-length tensor starts on an odd byte. Dereferencing a misaligned uint16_t* is undefined behavior regardless of whether x86 tolerates it in practice, and it is a real fault on stricter targets.

The other caller (:425) passes dq.data() from a std::vector<uint16_t>, which is suitably aligned. Only the :334 path is exposed.

Pre-existing, not introduced by the row that found it. git log -L 296,300 attributes the function to 8ee2c0766 ("Qwen3.6-35B MoE weight loader (NVFP4 dequant + stacked params + transpose)"). It surfaced now because #490s new test_qwen3_8_text_only builds synthetic checkpoints whose tensor offsets are not all even — which is a legitimate shape a real file can have.

Why no gate caught it before: the suites that exercise this path against real checkpoints are dgx-only and are not run under sanitizers, and the CPU sanitizer leg had no test that reached this loader until now. So the sanitizer lane and the loader coverage had never intersected.

Fix: load through std::memcpy (or char-wise) rather than dereferencing a cast pointer — the same treatment ReadScalarF32 at :288 already uses for exactly this reason, a few lines above. Worth grepping for sibling reinterpret_cast<... uint16_t*>(t.data) patterns in the loaders so the fix lands everywhere the assumption is made rather than only where UBSan happened to fire.

Any fix must prove inertness for the gated 27B/35B/Coder paths (golden md5 unchanged) since it touches the shared loader.

[localai-bot]

Fixed on #601 at 2608b813 — but the scope was wider than the one site UBSan reported, and four sites remain.

What the sweep found

A grep for reinterpret_cast<T*>(<sttensor>.data) across src/vllm/model_executor/models/ found 15 casts in 9 *_weights.cpp loaders, not one. Two are stricter alignment requirements than the 2-byte case CI happened to catch:

• olmo2_weights.cpp — forms a const float* (4-byte)
• qwen3_dspark_weights.cpp — forms a const int64_t* (8-byte)

All 15 are fixed in that PR.

The root cause is a seam violation

vt::LoadUnaligned (include/vt/unaligned.h) already existed — added by ea4deb203 — and dense_loaders::TransposeBf16 had already been migrated to it. minimax_h3_vae_loader.cpp:87 even carries a comment describing this exact bug.

qwen3_5_weights.cpp was keeping a private, unmigrated copy of TransposeBf16. So this was never a missing-helper problem; it was a hand-rolled parallel path that AGENTS.md §Shared seams already forbids. Worth remembering: the fix was adoption, not invention.

Still owed — outside that PRs authority

These carry the same defect and are not fixed:

site	severity
voxtral.cpp:51, voxtral.cpp:347	genuine misaligned load, same as the one UBSan caught
qwen3_vl.cpp:78	genuine misaligned load
qwen3_5_mtp.cpp:71	forms the pointer then memcpys — still UB, but will not trip the alignment check

A grep will not hold these. None is reached by a sanitized suite today, which is precisely why they survived: UBSan only fires where a test happens to run, and these paths have no sanitizer coverage. That makes them a coverage gap as much as a code gap — the honest fix pairs the migration with a sanitized test that reaches each loader.

Verification notes worth keeping

The fix is representation-only and was proven so three ways: a byte-equivalence harness comparing old vs new output at aligned bases (the only case the old code was defined) then reproducing those reference bytes at misaligned bases 1-8 with 0 mismatches; goldens untouched; both full suites 404/404 including a full ASan+UBSan serial run.

No performance cost. At -O2 the old and new inner loops are instruction-for-instruction identical — the memcpy folds into the same movzx WORD PTR load, no call emitted. The only delta is five prologue instructions paid once per call, not per element.

[localai-bot]

A sixth instance: ltx2_loader.cpp, the LTX-2.5 loader that landed after the sweep

main at cefacd2d0 is RED on sanitize-cpu (address,undefined) with this
issue's defect, in a file the #601 sweep could not have covered because it did
not exist yet:

src/vllm/model_executor/models/ltx2_loader.cpp:1288:91: runtime error:
load of misaligned address 0x7f7505e3d129 for type 'const uint16_t',
which requires 2 byte alignment

Reproduced locally under the CI lane's own configuration
(-DVLLM_CPP_SANITIZE='address,undefined', VT_POOL_BYPASS=1,
ASAN_OPTIONS=detect_leaks=1:strict_string_checks=1). The line has since moved
to :1334 under #654; it is the same statement, and the column matches.

Same root cause this issue already named. vt::LoadUnaligned existed. The
loader hand-rolled the cast instead. Adoption, not invention — for the second
time.

Sweep of the whole file, not just the reported line

UBSan only fires where a test reaches, so the line CI names is never the scope.
Every reinterpret_cast/static_cast off a raw payload pointer in
ltx2_loader.cpp:

site	verdict
:1324 reinterpret_cast<const uint16_t*>(t.data)	THE DEFECT — raw mapped payload. Fixed.
:131 reinterpret_cast<const char*>(marker.data)	safe: alignof(char) == 1, defined at any address
:328, :466 static_cast<const uint8_t*>(...data)	safe: alignof(uint8_t) == 1
:467, :495 reinterpret_cast<uint16_t*>(buffer.data())	safe: std::vector allocator storage
:636 reinterpret_cast<float*>(widened->bytes.data())	safe: same, owned vector
:1234 reinterpret_cast<const uint16_t*>(bytes.data())	safe: std::vector<uint8_t> filled by MaterializeDitTensor
:635 view.Ptr<uint16_t>()	safe: MakeView is only ever handed an owned buffer or device memory, never t.data

The two NVFP4 helpers (Ltx2UnswizzleNvfp4BlockScale, Ltx2DequantNvfp4ToBf16)
take the raw payload only as const uint8_t*, and ReadScalarF32 already
memcpys — the treatment this issue asked for.

So: one genuine site, six provably-aligned siblings, none left implicit.

Verification, in the form the earlier sweep set

• Byte-equivalence. Old vs new over 4096 values including the NaN / Inf /
  denormal / -0.0 bit patterns: IDENTICAL at an aligned base (the only case
  the old form was defined), and identical to the copied-to-aligned reference at
  misaligned bases 1-8. 0 mismatches.
• No cost. At -O2 the two inner loops are instruction-for-instruction
  identical — movzwl (%rdi,%rax,2) / sall $16 / movl — with zero call
  emitted and no memcpy symbol, matching what the earlier sweep observed.
• Inert. ltx2_goldens.inc md5 bf9e2757… unchanged; no golden file is in
  the diff. Serial ctest 423/423.
• Paired mutation. Reverting the fix reproduces the finding literally;
  restoring it returns exit 0.
• All seven LTX suites green under ASan+UBSan, zero findings: test_ltx2
  2435, test_ltx2_vae 3039, test_ltx2_text_encoder 4115, test_ltx2_pipeline
  2382, test_ltx2_loader 4826, test_ltx2_device 523, test_ltx2_video 502
  assertions.

The four sites recorded above are still owed

Re-checked on current main, all four unchanged and outside this branch's
authority:

• voxtral.cpp:51 — const auto* src = reinterpret_cast<const uint16_t*>(t.data);
• voxtral.cpp:347 — Bf16BitsToF32(reinterpret_cast<const uint16_t*>(t.data), n)
• qwen3_vl.cpp:78 — reinterpret_cast<const uint16_t*>(source.data) + offset
• qwen3_5_mtp.cpp:71 — forms the pointer then memcpys; still UB, still invisible to the alignment check

What this instance says about the fix

The earlier comment closed with "a grep will not hold these". This instance is
the evidence: the sweep was correct and complete for the files that existed, and
a new loader written afterwards reintroduced the defect anyway, because
nothing makes adopting the seam the path of least resistance for a new
*_loader.cpp. The durable fix is a checker in the shape of
check-device-leakage.py — a ratchet on reinterpret_cast off an StTensor
payload in src/vllm/model_executor/models/, with a per-site allowlist for the
provably-aligned cases — rather than another sweep. That belongs to whoever owns
this issue; recording it here rather than filing a duplicate.

Fixed on row/FIX-MAIN-RED-LTX25 alongside #553, #603, #651 and #652, which are
the other reds on the same main.

[localai-bot]

Sibling-site inventory, from the third recurrence of this class (#674).

The ltx2_loader.cpp instance red-ed main on sanitize-cpu (address,undefined) and is repaired on its own issue; this comment is the grep this issue asked for, so the remaining sites are visible rather than rediscovered a fourth time.

git grep -nE 'reinterpret_cast<const *(uint16_t|int64_t|float) *\*>\([a-z_]*(\.|->)data\)' -- src/vllm include/vllm at 43a6c5518 — every one of these forms a typed pointer over StTensor::data, i.e. straight into the safetensors mmap at an offset with no alignment guarantee:

file:line	pointer type	needs
gemma4_weights.cpp:138	const uint16_t* (s.data, into DequantFp8ChannelToBf16)	2
internlm2_weights.cpp:101	const uint16_t*	2
laguna_weights.cpp:267	const uint16_t*	2
olmo2_weights.cpp:83, 99, 139	const float*	4
parakeet_weights.cpp:103	const uint16_t*	2
phi_weights.cpp:64, 79, 118, 151	const uint16_t*	2
qwen3_5_dense_weights.cpp:117	const uint16_t*	2
qwen3_5_mtp.cpp:71	const uint16_t*	2
qwen3_5_weights.cpp:332, 346	const uint16_t*	2 — :332 is this issue's own site
qwen3_dspark_weights.cpp:99	const int64_t*	8 — the widest requirement in the tree
qwen3_vl.cpp:78	const uint16_t*	2
voxtral.cpp:51, 344	const uint16_t*	2

19 sites across 11 loaders. qwen3_dspark_weights.cpp:99 is worth calling out separately: an int64_t* needs 8-byte alignment, so it is UB on 7 of every 8 possible offsets rather than 1 of 2, and nothing about a d2t tensor's position in a checkpoint makes 8-byte alignment likely.

Checked and NOT on the list, so a future sweep does not churn them: kimi_linear_device.cpp:2129 (row derives from a std::vector<uint8_t> base with an even stride), ltx2_loader.cpp:1234 and qwen3_dspark_weights.cpp:126 (both over std::vector::data(), which is suitably aligned), ltx2_loader.cpp:635 (view.Ptr<uint16_t>() over an owned host buffer), and every memcpy/const char* read, which have no alignment precondition.

Why none of them is firing today: the CPU sanitizer lane's fixtures happen to land these tensors on even offsets. That is luck, not a guarantee — #674's site was caught only because the LTX-2.5 fixture's JSON header happens to be an odd length. Any fixture rename or reshape moves every offset in the file.

The seam to use is already here: vt::LoadUnaligned<T> (include/vt/unaligned.h), which #301 left behind, and minimax_h3_vae_loader.cpp:87-101 carries the same repair with the reasoning in prose.

Not swept in #674's PR deliberately: this issue requires 27B/35B/Coder golden-md5 inertness evidence for the shared loader, and that repair had no GPU. The sweep is mechanical and value-identical by construction, but it owes that evidence on a box that can produce it.

There is also a gate-shaped observation for whoever takes this: three separate in-tree records of this bug class (#301's seam, minimax_h3_vae_loader's comment, this issue) did not stop a fourth loader landing with the cast. Nothing greps for reinterpret_cast<...>(t.data), and a checker that did would have caught all 19 at once.

[localai-bot]

The inventory dismisses one site on a premise that does not hold

Found by a fresh review of #688 (which is sound, and PASSED — this is about the inventory posted here, not that fix).

This issue's inventory dismisses qwen3_dspark_weights.cpp:126 as "over std::vector::data(), suitably aligned". It is not a std::vector.

markov_w1 is an OwnedTensor whose bytes is an OwnedBytes (qwen3_5_weights.h:45-50), and that type is documented as possibly holding "a read-only borrowed view (GGUF mmap)" — in which case OwnedBytes::data() returns the borrowed pointer, carrying exactly the same absence of alignment guarantee as the safetensors payload offset that produced #674.

The same applies to every other .bytes.data() cast on the list: roughly ten in gemma4_moe.cpp, plus qwen3_5.cpp:940, deepseek_v2_weights.cpp:146, kimi_linear_weights.cpp:541, minicpm3_weights.cpp:84. Re-derive each of these at HEAD before acting — anchors in this tree go stale within a single PR — and use a positive control in the same grep rather than trusting a null result.

Why this matters more than the count. GGUF usually aligns tensor data, so these may well be fine in practice. But "aligned in practice" is precisely the reasoning that produced this bug three times: #301 (closed, and it is what left the vt::LoadUnaligned seam behind), #627 (qwen3_5_weights.cpp, still open), and now #674. A site classified as safe because it happens to be aligned is not classified; it is deferred, and the deferral is invisible.

The honest disposition for each is one of: route it through vt::LoadUnaligned, or record the alignment guarantee that actually holds with the anchor that provides it — not the container it superficially resembles.

One more, for the same sweep

minimax_h3_vae_loader.cpp:96-101 hand-rolls the same memcpy rather than calling vt::LoadUnaligned. #688 uses the seam correctly; this one is a parallel path of the kind AGENTS.md forbids, and it belongs in this sweep rather than in its own row.

Related: #674, #688, #301, #687 (six hand-rolled path helpers with divergent semantics — same disease, different seam).