https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
Bug ID: 94823
Summary: modulo arithmetic bug in random.tcc
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
I think there's a bug in libstdc++v3/include/bits/random.tcc, found by ubsan's
(over conservative) unsigned overflow checker. This time, a true positive.
there's a bunch of code like:
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]); // this line
... calculate stuff
__begin[(__k + __p) % __n] += __r1;
__begin[(__k + __q) % __n] += __r2;
__begin[__k % __n] = __r2;
}
AFAICT we're treating __begin as a circular buffer length __n. __n has no
special properties. The marked line is presuming that '(V mod 2^n) mod __n' is
the same as '(V mod __n)' which is not true in general. In particular when
__k is zero we're taking '(2^64 - 1) mod __n', which is not necessarily __n -
1, the last position in the buffer, right?
I don't know if the prior line __k + __p can overflow too. If it can't then I
think the marked line should be:
__begin[(__k + __n - 1) % __n]
