aboutsummaryrefslogtreecommitdiff
path: root/src/liblzma/common/index_decoder.c
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2023-02-21 22:57:10 +0200
committerLasse Collin <lasse.collin@tukaani.org>2023-02-23 20:41:22 +0200
commit30e95bb44c36ae26b2ab12a94343b215fec285e7 (patch)
tree2c9488109beb32373c2e7b507e451b0780daaa8a /src/liblzma/common/index_decoder.c
parentliblzma: Adjust container.h for consistency with filter.h. (diff)
downloadxz-30e95bb44c36ae26b2ab12a94343b215fec285e7.tar.xz
liblzma: Avoid null pointer + 0 (undefined behavior in C).
In the C99 and C17 standards, section 6.5.6 paragraph 8 means that adding 0 to a null pointer is undefined behavior. As of writing, "clang -fsanitize=undefined" (Clang 15) diagnoses this. However, I'm not aware of any compiler that would take advantage of this when optimizing (Clang 15 included). It's good to avoid this anyway since compilers might some day infer that pointer arithmetic implies that the pointer is not NULL. That is, the following foo() would then unconditionally return 0, even for foo(NULL, 0): void bar(char *a, char *b); int foo(char *a, size_t n) { bar(a, a + n); return a == NULL; } In contrast to C, C++ explicitly allows null pointer + 0. So if the above is compiled as C++ then there is no undefined behavior in the foo(NULL, 0) call. To me it seems that changing the C standard would be the sane thing to do (just add one sentence) as it would ensure that a huge amount of old code won't break in the future. Based on web searches it seems that a large number of codebases (where null pointer + 0 occurs) are being fixed instead to be future-proof in case compilers will some day optimize based on it (like making the above foo(NULL, 0) return 0) which in the worst case will cause security bugs. Some projects don't plan to change it. For example, gnulib and thus many GNU tools currently require that null pointer + 0 is defined: https://lists.gnu.org/archive/html/bug-gnulib/2021-11/msg00000.html https://www.gnu.org/software/gnulib/manual/html_node/Other-portability-assumptions.html In XZ Utils null pointer + 0 issue should be fixed after this commit. This adds a few if-statements and thus branches to avoid null pointer + 0. These check for size > 0 instead of ptr != NULL because this way bugs where size > 0 && ptr == NULL will likely get caught quickly. None of them are in hot spots so it shouldn't matter for performance. A little less readable version would be replacing ptr + offset with offset != 0 ? ptr + offset : ptr or creating a macro for it: #define my_ptr_add(ptr, offset) \ ((offset) != 0 ? ((ptr) + (offset)) : (ptr)) Checking for offset != 0 instead of ptr != NULL allows GCC >= 8.1, Clang >= 7, and Clang-based ICX to optimize it to the very same code as ptr + offset. That is, it won't create a branch. So for hot code this could be a good solution to avoid null pointer + 0. Unfortunately other compilers like ICC 2021 or MSVC 19.33 (VS2022) will create a branch from my_ptr_add(). Thanks to Marcin Kowalczyk for reporting the problem: https://github.com/tukaani-project/xz/issues/36
Diffstat (limited to '')
-rw-r--r--src/liblzma/common/index_decoder.c13
1 files changed, 10 insertions, 3 deletions
diff --git a/src/liblzma/common/index_decoder.c b/src/liblzma/common/index_decoder.c
index 8622b2f0..19a31b3e 100644
--- a/src/liblzma/common/index_decoder.c
+++ b/src/liblzma/common/index_decoder.c
@@ -203,9 +203,16 @@ index_decode(void *coder_ptr, const lzma_allocator *allocator,
}
out:
- // Update the CRC32,
- coder->crc32 = lzma_crc32(in + in_start,
- *in_pos - in_start, coder->crc32);
+ // Update the CRC32.
+ //
+ // Avoid null pointer + 0 (undefined behavior) in "in + in_start".
+ // In such a case we had no input and thus in_used == 0.
+ {
+ const size_t in_used = *in_pos - in_start;
+ if (in_used > 0)
+ coder->crc32 = lzma_crc32(in + in_start,
+ in_used, coder->crc32);
+ }
return ret;
}