SparseDem::from_dem_str (and the sibling parsers in the same file) compute dimension
counts as:
num_detectors: max_detector.map_or(0, |m| m as usize + 1),
num_observables: max_observable.map_or(0, |m| m as usize + 1),
at crates/pecos-decoder-core/src/dem.rs:401-402, with the same pattern repeated at
dem.rs:555-556 and dem.rs:842-843.
On a 32-bit target (usize == u32), a DEM containing the maximal index — D4294967295
or L4294967295 — makes m as usize + 1 overflow: a panic in debug builds, and a
silent wrap to 0 in release builds. The release behavior is the worse one: the parser
returns a structurally valid SparseDem whose num_detectors/num_observables is 0
while mechanisms still contains the out-of-range indices, so the error surfaces later
(or not at all) far from the cause.
Unreachable on 64-bit targets (u32::MAX as usize + 1 fits comfortably), so nothing
currently deployed is affected. It becomes relevant if any consumer of
pecos-decoder-core is ever built for a 32-bit target (e.g. wasm32), and the parser
is a boundary that accepts arbitrary caller-supplied DEM text — including, if the
shot-corpus work on the decoder-eval-harness branch lands, text embedded in files
read from disk.
Suggested fix: checked_add(1) (or promote through u64/usize::try_from) and return
DecoderError::InvalidConfiguration naming the offending index, at all three sites.
Found during a robustness review of the corpus loader on decoder-eval-harness
(PR #432); recorded here because the defect is pre-existing on dev and independent of
that branch.
SparseDem::from_dem_str(and the sibling parsers in the same file) compute dimensioncounts as:
at
crates/pecos-decoder-core/src/dem.rs:401-402, with the same pattern repeated atdem.rs:555-556anddem.rs:842-843.On a 32-bit target (
usize == u32), a DEM containing the maximal index —D4294967295or
L4294967295— makesm as usize + 1overflow: a panic in debug builds, and asilent wrap to
0in release builds. The release behavior is the worse one: the parserreturns a structurally valid
SparseDemwhosenum_detectors/num_observablesis0while
mechanismsstill contains the out-of-range indices, so the error surfaces later(or not at all) far from the cause.
Unreachable on 64-bit targets (
u32::MAX as usize + 1fits comfortably), so nothingcurrently deployed is affected. It becomes relevant if any consumer of
pecos-decoder-coreis ever built for a 32-bit target (e.g.wasm32), and the parseris a boundary that accepts arbitrary caller-supplied DEM text — including, if the
shot-corpus work on the
decoder-eval-harnessbranch lands, text embedded in filesread from disk.
Suggested fix:
checked_add(1)(or promote throughu64/usize::try_from) and returnDecoderError::InvalidConfigurationnaming the offending index, at all three sites.Found during a robustness review of the corpus loader on
decoder-eval-harness(PR #432); recorded here because the defect is pre-existing on
devand independent ofthat branch.