# DF-5363 -- CISTPL_CHECKSUM bounds check ignores tuple.mult: up to 4088 bytes of bus reads past the 4096-byte CIS mapping

File: sys/bus/pccard/pccard_cis.c (verify pass, GLM 5.3).  Full narrative: VERDICT.md.

## Reproduce (verbatim production parser, guest toolchain, no PCMCIA HW needed)
    ./build.sh          # sh extract.sh .  &&  cc -O2 -Wall -o rig rig_main.c
    ./run.sh            # baseline scenarios: ./rig checksum && ./rig checksum_ok
    sh run_matrix.sh    # A/B: baseline vs each single-fix variant, all scenarios

Expected decisive output (DF-5363): BASELINE: CHECKSUM tuple with offset=4, length=4091 passes the :247-249 check (4+4091=4095 < 4096) but the read loop magnifies i by tuple.mult=2 -> exactly 2045 out-of-mapping bus reads at offsets 4096..8184 (max 8184 = 2.00x the mapping), scan then terminates normally. checksum_ok (offset 0, length 100): 0 OOB. WITH fix.diff (f5363): the magnified bound rejects the crafted tuple ('too distant') -> 0 OOB; checksum_ok still accepted (110 in-window reads); all other scenarios unchanged.

## What it proves
The rig executes the **byte-identical production parser** extracted from the
guest's /usr/src (sha256-gated; extract_manifest.txt) through the real entry
`pccard_read_cis()`. Kernel entry is hardware-gated (no PCMCIA bridge in
QEMU) -- see VERDICT.md for the method, the A/B matrix, and the
booted-combined-fix-kernel validation.

Recommended fix: Magnify the length term in the too-distant check: 'addr + tuple.mult * length >= PCCARD_CIS_SIZE' instead of 'addr + length >= PCCARD_CIS_SIZE'. (fix.diff; validated, see fixed_run.log /
matrix.log / postboot_run.log).

Note: `poc_pccard_cis2.c` is the seeded hand-written model from the earlier
model-only verdict (status was `untested`); it is kept for history and is
SUPERSEDED by the verbatim rig (`extract.sh` + `rig_main.c` + `rig_shims.h`)
which reproduces its numbers on the byte-identical production parser.