Hi,

CVE-2026-120457 was published for libaec: in m_se_decode() (src/decode.c),
the slow path of the Second Extension decoder, the fundamental sequence
length is stored in a signed int32_t taken from the uint32_t state->fs. A
sequence of 2^31 or more zero bits makes it negative, so the "m >
SE_TABLE_SIZE" check passes and se_table is read out of bounds. The slow
path is used when the output buffer is smaller than one block.

Upstream fixed it in commit efcc8f200fdc5fc674353cebcb20c1fe197bc055 ("Use
unsigned FS length in m_se_decode", upstream issue 64, PR 66), which
changes "int32_t m;" to "uint32_t m;" and adds a regression test
(check_se_huge_fs_small_output in tests/check_corrupt_input.c). The fix is
part of upstream release 1.1.8 (2026-11-04). The 1.1.8 changelog also lists
other memory-safety fixes: a heap buffer overflow in SZ_BufftoBuffCompress
with negative parameters, a heap buffer overflow when decoding resumed
after AEC_DATA_ERROR, and uninitialized memory returned by aec_decode_range
and SZ_BufftoBuffDecompress for truncated input.

The vulnerable code is present in 1.0.4-1, 1.0.6-1, 1.1.3-1 and 1.1.7-1;
the one-line src/decode.c hunk applies to all of them with "patch -p1
--dry-run" (only line offsets differ).

I built upstream's regression test (tests/check_corrupt_input.c from 1.1.8)
against the 1.1.3-1 decoder with ASan/UBSan and got:

src/decode.c:551:36: runtime error: signed integer overflow: -2147483644 *
2 cannot be represented in type 'int'

With 1.1.8 the same test passes. (Against 1.1.7-1 the test program stops
earlier at an unrelated check that 1.1.8 also fixes, so for 1.1.7-1 this is
based on the code and the patch dry-run.)

The security tracker marks this no-dsa for trixie and postponed for
bookworm, so packaging 1.1.8 in unstable (or applying the one-line patch)
should be enough.

Thanks,
Sumit Verma