Negative array access on state->mtf for InverseMoveToFrontTransform #104

New Issue

claunia · 2026-01-29T20:34:49Z

claunia commented

2026-01-29 20:34:49 +00:00

Originally created by @danielrh on GitHub (Apr 18, 2016).

When decoding quickfox_repeated.compressed
The local variable index can start off zero, which will result in an access to s.mtf[-1]
https://github.com/google/brotli/blob/master/dec/decode.c#L881

Since the previous variable in the struct is a 32 bit integer mtf_upper_bound, and usually little endian < 2^24, this generally results in a zero access.

I believe this could exhibit itself as an issue on big endian systems and could be undefined behavior nevertheless. I think it would be more intuitive to restructure the code to avoid out of bounds access.

Originally created by @danielrh on GitHub (Apr 18, 2016). When decoding quickfox_repeated.compressed The local variable `index` can start off zero, which will result in an access to s.mtf[-1] https://github.com/google/brotli/blob/master/dec/decode.c#L881 Since the previous variable in the struct is a 32 bit integer mtf_upper_bound, and usually little endian < 2^24, this generally results in a zero access. I believe this could exhibit itself as an issue on big endian systems and could be undefined behavior nevertheless. I think it would be more intuitive to restructure the code to avoid out of bounds access.

claunia closed this issue

2026-01-29 20:34:50 +00:00

claunia commented

2026-01-29 20:34:52 +00:00

@eustas commented on GitHub (Apr 18, 2016):

Hello, Daniel.

Thank you for your report. Actually, the value taken from negative index lives very shortly - it is overwritten by mtf[0] = value. Nevertheless, going to fix it soon.

@eustas commented on GitHub (Apr 18, 2016): Hello, Daniel. Thank you for your report. Actually, the value taken from negative index lives very shortly - it is overwritten by mtf[0] = value. Nevertheless, going to fix it soon.

claunia commented

2026-01-29 20:34:54 +00:00

@eustas commented on GitHub (Apr 29, 2016):

Fixed in PR #343

@eustas commented on GitHub (Apr 29, 2016): Fixed in PR #343

claunia referenced this issue

2026-01-29 20:50:28 +00:00

[PR #104] [MERGED] [python] fix compatibility_test.py with Python 3 #710

Sign in to join this conversation.