Fix: trace-chunk: dereference after NULL check
authorJérémie Galarneau <jeremie.galarneau@efficios.com>
Mon, 3 Feb 2020 19:34:53 +0000 (14:34 -0500)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Mon, 3 Feb 2020 19:34:53 +0000 (14:34 -0500)
old_path is used directly even though it is checked for NULL. The
situation highlighted by Coverity does not appear to be possible given
the current use of the API. However, it should still be checked to
catch future errors (or current bugs).

1412200 Dereference after null check

Either the check against null is unnecessary, or there may be a null
pointer dereference.

In lttng_trace_chunk_rename_path_no_lock: Pointer is checked against
null but then dereferenced anyway (CWE-476)

Reported-by: Coverity Scan
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: I991231cc636eaed98cb84eec08a5072748ff9ef4

src/common/trace-chunk.c

index f909a682f6b376769b9cdbd27662e7d36f5e64b7..ea952220b880ad4a12e106a13c90973cfdda1d19 100644 (file)
@@ -859,7 +859,7 @@ enum lttng_trace_chunk_status lttng_trace_chunk_rename_path_no_lock(
                 */
                chunk->chunk_directory = rename_directory;
                rename_directory = NULL;
-       } else {
+       } else if (old_path) {
                size_t i, count = lttng_dynamic_pointer_array_get_count(
                                &chunk->top_level_directories);
                const bool reference_acquired = lttng_directory_handle_get(
@@ -908,6 +908,10 @@ enum lttng_trace_chunk_status lttng_trace_chunk_rename_path_no_lock(
                        ret = -1;
                        goto end;
                }
+       } else {
+               /* Unexpected !old_path && !path. */
+               status = LTTNG_TRACE_CHUNK_STATUS_INVALID_ARGUMENT;
+               goto end;
        }
 
 skip_move:
This page took 0.034822 seconds and 4 git commands to generate.