Re: Fwd: New Defects reported by Coverity Scan for git
- From
René Scharfe <l.s.r@web.de>
- Date
- Jul 20, 2017, 20:32 UTC
- Message-ID
- <0110b370-a515-df44-8d46-9a72ac336ee7@web.de>
- In-Reply-To
- <xmqqa841fylf.fsf@gitster.mtv.corp.google.com>
Am 18.07.2017 um 19:23 schrieb Junio C Hamano:
Show 16 quoted lines
> Stefan Beller <sbeller@google.com> writes: > >> I looked at this report for a while. My current understanding: >> * its detection was triggered by including rs/move-array, >> f331ab9d4c (use MOVE_ARRAY, 2017-07-15) >> * But it is harmless, because the scan logic does not understand >> how ALLOC_GROW works. It assumes that >> done_pbase_paths_alloc can be larger >> than done_pbase_paths_num + 1, while done_pbase_paths >> is NULL, such that the memory allocation is not triggered. >> If that were the case, then we have 2 subsequent dereferences >> of a NULL pointer right after that. But by inspecting the use >> of _alloc and _num the initial assumption does not seem possible. > > Yes, it does appear that way. ALLOC_GROW() calls REALLOC_ARRAY() > which safely can realloc NULL to specified size via xrealloc().
MOVE_ARRAY is passing its pointer arguments to memmove(); all it adds is a check for (done_pbase_paths_num - pos - 1) being zero. I don't understand how that change can make it more likely for one of the pointers to be NULL.
I guess the first message ('Comparing "done_pbase_paths" to null implies that "done_pbase_paths" might be null.') has to be understood as an explanation of how the checker arrived at the second one?
We could remove that NULL check -- it's effectively just a shortcut. But how would that improve safety? Well, if the array is unallocated (NULL) and _num is greater than zero we'd get a segfault without it, and thus would notice it. That check currently papers over such a hypothetical bug. Makes sense?
-- >8 -- Subject: [PATCH] pack-objects: remove unnecessary NULL check
If done_pbase_paths is NULL then done_pbase_paths_num must be zero and done_pbase_path_pos() returns -1 without accessing the array, so the check is not necessary.
If the invariant was violated then the check would make sure we keep on going and allocate the necessary amount of memory in the next ALLOC_GROW call. That sounds nice, but all array entries except for one would contain garbage data.
If the invariant was violated without the check we'd get a segfault in done_pbase_path_pos(), i.e. an observable crash, alerting us of the presence of a bug.
Currently there is no such bug: Only the functions check_pbase_path() and cleanup_preferred_base() change pointer and counter, and both make sure to keep them in sync. Get rid of the check anyway to allow us to see if later changes introduce such a defect, and to simplify the code.
Detected by Coverity Scan.
Signed-off-by: Rene Scharfe <l.s.r@web.de> --- builtin/pack-objects.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index e730b415bf..c753e9237a 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1289,7 +1289,7 @@ static int done_pbase_path_pos(unsigned hash) static int check_pbase_path(unsigned hash) { - int pos = (!done_pbase_paths) ? -1 : done_pbase_path_pos(hash); + int pos = done_pbase_path_pos(hash); if (0 <= pos) return 1; pos = -pos - 1;
-- 2.13.3