An assertion failure was possible to trigger in jas_seq2d_create.
Created mingw-jasper tracking bugs for this issue:
Affects: fedora-all [bug 1396987]
Affects: epel-7 [bug 1396989]
Created jasper tracking bugs for this issue:
Affects: fedora-all [bug 1396986]
Affects: epel-5 [bug 1396988]
Upstream bug report:
Original reporter's advisory:
Relevant information from the advisory:
Affected version: 1.900.22
warning: trailing garbage in marker segment (9 bytes)
warning: trailing garbage in marker segment (40 bytes)
warning: ignoring unknown marker segment (0xffee)
type = 0xffee (UNKNOWN); len = 23;1f 32 ff ff ff 00 10 00 3d 4d 00 01 32 ff 00 e4 00 10 00 00 4f warning: trailing garbage in marker segment (34 bytes)
imginfo: /tmp/portage/media-libs/jasper-1.900.22/work/jasper-1.900.22/src/libjasper/base/jas_seq.c:90: jas_matrix_t *jas_seq2d_create(int, int, int, int): Assertion `xstart <= xend && ystart <= yend' failed.
Fixed version: 1.900.25
The problem triggered by the reporter's reproducer is that the jas_seq2d_create() function is called with arguments taken from variables of the uint_fast32_t type, while all function arguments are of type int. One of the values passed is greater than INT_MAX, causing it to be interpreted as negative in jas_seq2d_create(), resulting in end value greater than start value.
One change included in the commit d42b238 linked above, that was applied in version 1.900.25, is change of the jas_seq2d_create() argument types form in to int_fast32_t. On certain architectures, such as x86_64, int_fast32_t is 64 bit type, while int is 32 bit. Therefore, values between INT_MAX and UINT_MAX are no longer handled as negative in jas_seq2d_create(). The same would not apply to architectures where sizeof(int) == sizeof(int_fast32_t). It is unclear if it would be possible to call the function with values over 2^63, which would cause similar problem for 64 bit int_fast32_t.
It should also be noted that the fix changes public API/ABI, and hence can not be backported as is. The provided reproducer also does not trigger assertion failure once other security fixes are applied. Considering all this, there's currently no plan to fix this problem in released Red Hat Enterprise Linux versions.