On Tue, May 14, 2024 at 02:17:16PM +0000, Qing Zhao wrote:
> The current major issue with the warning is: the constant index value 4
> is not in the source code, it’s a compiler generated intermediate value
> (even though it’s a correct value -:)). Such warning messages confuse
> the end-users with information that cannot be connected directly to the
> source code.
Right -- this "4" comes from -fsanitize=array-bounds (in "warn but
continue" mode).
Now, the minimized PoC shows a situation that triggers the situation, but
I think it's worth looking at the original code that caused this false
positive:
for (i = 0; i < sg->num_entries; i++) {
gce = &sg->gce[i];
The issue here is that sg->num_entries has already been bounds-checked
in a separate function. As a result, the value range tracking for "i"
here is unbounded.
Enabling -fsanitize=array-bounds means the sg->gce[i] access gets
instrumented, and suddenly "i" gains an implicit range, induced by the
sanitizer.
(I would point out that this is very similar to the problems we've had
with -fsanitize=shift[1][2]: the sanitizer induces a belief about a
given variable's range this isn't true.)
Now, there is an argument to be made that the original code should be
doing:
for (i = 0; i < 4 && i < sg->num_entries; i++) {
But this is:
a) logically redundant (Linux maintainers don't tend to like duplicating
their range checking)
b) a very simple case
The point of the sanitizers is to catch "impossible" situations at
run-time for the cases where some value may end up out of range. Having
it _induce_ a range on the resulting code makes no sense.
Could we, perhaps, have sanitizer code not influence the value range
tracking? That continues to look like the root cause for these things.
-Kees
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--
Kees Cook
