Stop a non-finite RAT value in a PAM sidecar from crashing open_geotiff#3594
Conversation
read_pam_sidecar() must never raise on a bad sidecar: open_geotiff()
reads the PAM .aux.xml for any local string source, and a malformed
sidecar degrades to {} rather than breaking the read (#3520, #3522).
_parse_rat() converts a thematic RAT's Value cell with
int(float(text)). A cell like "1e400" or "inf" makes int() raise
OverflowError, which subclasses ArithmeticError rather than ValueError,
so the (OSError, ValueError, TypeError, IndexError, ParseError) tuple
did not cover it. The exception escaped and crashed the read.
Add OverflowError to the caught exceptions so an infinite Value cell
falls back to {} like every other malformed case. Found by
/sweep-security; also records the sweep state update.
Closes #3590
brendancol
added
bug
brendancol
left a comment
brendancol
left a comment
There was a problem hiding this comment.
Domain-aware review (rockout step 9, /sweep-security run).
Scope: one-line exception-tuple widening in read_pam_sidecar() plus a regression test and the sweep state CSV row. Matches the precedent set by #3522, which added IndexError and ParseError to the same tuple for the same fail-closed contract.
Blockers: none.
Suggestions: none. I checked the other conversions in _parse_rat for sibling gaps: int(usage_el.text), int(fd.get('index')), int(row.get('index')), and the RGBA int(fields[c]) all raise ValueError/TypeError on bad text (including '1e400', which int() refuses directly), and int(float('nan')) raises ValueError. Only the Value cell's int(float(...)) path can produce OverflowError, so the one added type closes the gap. Catching it in read_pam_sidecar rather than clamping inside _parse_rat keeps behaviour consistent with the short-row case (whole sidecar degrades to {}).
Nits: none. Test filename embeds the issue number per project convention, and the sidecar XML mirrors the neighbouring #3520 test.
Verified locally: the new test fails with OverflowError on the parent commit and passes with the fix; the end-to-end repro from #3590 (open_geotiff on a TIFF beside the adversarial sidecar) now opens and ignores the sidecar. Full test file: 21 passed.
…eotiff-2026-07-01
1 participant
Closes #3590
A thematic RAT
<F>Value cell whose text parses to infinity (1e400,inf,-inf) madeint(float(...))in_parse_ratraiseOverflowError. That subclassesArithmeticError, notValueError, so it slipped pastread_pam_sidecar()'s fail-closed except tuple and crashed theopen_geotiff()call for any local source with such a sidecar next to it. Same contract violation as #3520/#3522, reached through a different exception.OverflowErrorto the caught exceptions inread_pam_sidecar()so an infinite Value cell degrades to{}like every other malformed-sidecar case.test_non_finite_rat_value_returns_emptyalongside the GeoTIFF: a crafted .aux.xml sidecar crashes open_geotiff with IndexError #3520 short-row test; it fails withOverflowErrorbefore the fix..claude/sweep-security-state.csvupdate (found by/sweep-security).Backend coverage: the sidecar read happens in
open_geotiffafter backend dispatch on all four read paths (eager, gpu, dask+numpy, dask+gpu), so the fix covers them all; no kernel or graph code touched.Test plan:
pytest xrspatial/tests/test_rasterize_categorical_3482.py(21 passed)open_geotiffon a TIFF with the adversarial sidecar now opens and ignores it