Skip to main content

Browse the archive

https://github.com/git/git
05 April 2024, 19:32:26 UTC
Revision e1e12e97ac73ded85f7d000da1063a774b3cc14f authored by Patrick Steinhardt on 01 December 2022, 14:45:36 UTC, committed by Junio C Hamano on 05 December 2022, 06:14:16 UTC 
attr: fix integer overflow with more than INT_MAX macros
 
Attributes have a field that tracks the position in the `all_attrs`
array they're stored inside. This field gets set via `hashmap_get_size`
when adding the attribute to the global map of attributes. But while the
field is of type `int`, the value returned by `hashmap_get_size` is an
`unsigned int`. It can thus happen that the value overflows, where we
would now dereference teh `all_attrs` array at an out-of-bounds value.

We do have a sanity check for this overflow via an assert that verifies
the index matches the new hashmap's size. But asserts are not a proper
mechanism to detect against any such overflows as they may not in fact
be compiled into production code.

Fix this by using an `unsigned int` to track the index and convert the
assert to a call `die()`.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent 447ac90
Raw File
Tip revision: e1e12e97ac73ded85f7d000da1063a774b3cc14f authored by Patrick Steinhardt on 01 December 2022, 14:45:36 UTC
attr: fix integer overflow with more than INT_MAX macros
Tip revision: e1e12e9
.tsan-suppressions 
# Suppressions for ThreadSanitizer (tsan).
#
# This file is used by setting the environment variable TSAN_OPTIONS to, e.g.,
# "suppressions=$(pwd)/.tsan-suppressions". Observe that relative paths such as
# ".tsan-suppressions" might not work.

# A static variable is written to racily, but we always write the same value, so
# in practice it (hopefully!) doesn't matter.
race:^want_color$
race:^transfer_debug$

# A boolean value, which tells whether the replace_map has been initialized or
# not, is read racily with an update. As this variable is written to only once,
# and it's OK if the value change right after reading it, this shouldn't be a
# problem.
race:^lookup_replace_object$
back to top