The CPU paged attention reads past a block table shorter than the sequence it addresses, and the W6 seam case supplies one

[localai-bot]

vt::cpu::PagedAttentionKernel reads btab[r * bt_row + (j / block_size) * bt_col] for every j < seq_lens[r] and never checks that the block table has that many columns. A caller that supplies a table shorter than ceil(seq_lens[r] / block_size) gets an out-of-bounds read of the tensor's own storage, a plausible-looking block index out of it, and attention over the wrong page. Nothing faults and nothing is reported.

tests/vllm/models/test_qwen3_5_decode_graph_seam.cpp supplies exactly that. Its SpecAttnMeta helper hardcoded block_table_num_cols = 1 with one entry per request, while shape C of the W6 case sits at pos = 20 with q = 4, so seq_lens = 24 against CachePool's block_size = 16 and the kernel reads column 1 of a one-column table.

It was silent until the neighbouring bytes moved. Found while fixing #1380: a DevicePool change altered which pooled block holds the table and therefore what follows it, and the same read became a SIGSEGV on thor:gpu0. gdb at src/vt/cpu/cpu_paged_attn.cpp:224, one frame under FullAttnBlockPaged, reached from the eager fallback of Qwen3_5DecodeGraph::Step for that shape. The case passes at origin/main (8 cases / 138 assertions) purely because the read landed on bytes that decoded to an in-range block index.

Both halves are fixed in the same flow, per AGENTS.md: the kernel refuses a short table with one compare per request outside the token loop, and the test's helper sizes its block table for the sequence length it declares.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

[localai-bot]

CORRECTION, and it raises the severity. This issue's body says the seam case "passes at origin/main" and calls the read "not a latent crash". The first half was a statement about ONE build presented as a statement about the tree, and it is withdrawn.

Two readings of tests/vllm/models/test_qwen3_5_decode_graph_seam.cpp at 5f68e60df exactly:

where	result
thor:gpu0, CUDA-ON build, /tmp incremental build dir	8 cases, 138 assertions, 0 failed, exit 0
operator's build	deterministic SIGSEGV, exit 139, 3 runs of 3

Both are real. Together they say the read is out of bounds at main unconditionally, and that whether it FAULTS is the allocator's business rather than the caller's: a deterministic crash in natural case order on one build, silent wrong-page attention on another. So this closes a live crash on main, not only a latent hazard.

What settles the presence of the defect independently of any heap layout is already measured: origin/main built with ONLY the kernel refusal added and WITHOUT the test-data fix — the refusal fired. A predicate over seq_lens[r], block_size and block_table.shape[1] cannot depend on what follows an allocation.

The assertion counts never disagreed. A SIGSEGV truncates doctest's count: 135 is a run of the same 8 cases that crashed inside the last one, so the three assertions after the crash point are never counted, and 138 is the complete run. git diff shows #1393 adds no assertion to that file, and the file is byte-identical between 5f68e60df and 96ed8346f.

The .agents/issue-index.md row still carries the withdrawn wording. That file is append-only with one row per issue, so the correction lives in .agents/specs/eng-cudagraph-break.md and in this comment rather than as an edit or a second row.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]