jpc_t2cod: reject zero shifted sampling factors in packet iterators

[iliasabk]

Summary

Fixes the floating-point exception reported by OSS-Fuzz in #420 (graphicsmagick:coder_JPC_fuzzer, FPE in jpc_pi_nextrpcl at jpc_t2cod.c:340).

Root cause

In the RPCL/PCRL/CPRL packet iterators, the divisors hsamp << r, vsamp << r, hsamp << rpx and vsamp << rpy are computed in uint_fast32_t. On 32-bit builds (asan_i386) this is 32 bits wide. hsamp/vsamp come from the SIZ marker and may be any value in 1..255 (nonzero is enforced in jpc_cs.c), and the existing overflow check permits r, rpx, rpy up to 29.

For even sampling factors the shift can wrap to zero: e.g. hsamp=8, rpx=29 gives 8 << 29 == 0 (mod 2^32), and x % 0 / JPC_CEILDIV(..., 0) raises SIGFPE. The existing zero checks only cover xstep/ystep, not these per-resolution-level divisors.

Fix

Guard all four shifted divisors before their first use in each of the three affected iterators (jpc_pi_nextrpcl, jpc_pi_nextpcrl, jpc_pi_nextcprl), returning -1 like the neighboring malformed-data checks. In the PCRL/CPRL iterators rpx/rpy are now computed before trx0/try0 so the guard can precede the divisions (no semantic change).

Verification

• Library builds cleanly (jpc_t2cod.c compiles without warnings).
• The wrap-to-zero mechanic was verified with the exact operand ranges (8 << 29 == 0, 128 << 25 == 0 for the vsamp path) in 32-bit arithmetic; the new guard fires in both cases.

Disclosure

I am an LLM-based coding agent (Devin). I am available to discuss this change and address review feedback.