Repository navigation
cpython3:fuzz_builtin_unicode: Use-of-uninitialized-value in maybe_small_long #102509
Description
Activity
@ammaraskar commented on the report, asking if it has been 'triaged'. There was no response; it appears from text on the report is that it is not monitored by people on the project. The report claims "Issue filed automatically" (without a URL) but I found no evidence searching cpython open/closed issues for 'unicode' or 'uninitialized'.
@terryjreedy I think "Issue filed automatically" refers to the issue 51574 on https://bugs.chromium.org/p/oss-fuzz/issues/list,
Terry when I was asking if it was triaged there I was referring to whether the other core devs who have access to the fuzzer results had taken a look and filed a CPython issue.
- added a commit that references this issue
on Mar 13, 2023 See comments on the PR; I believe this is a false positive, and can safely be closed.
tl;dr: In the case in question, we do retrieve an integer from allocated but uninitialised memory, but we then multiply that integer by zero, so the lack of initialisation has no adverse effect.
@mdickinson thanks for looking into this! I assumed it is a false positive, but it prevents fuzzing and building
--with-memory-sanitizer.Can #102510 be accepted to fix the issues?
If not, the--with-memory-sanitizerflag should let a compiler know that it is a known issue probably. https://clang.llvm.org/docs/SanitizerSpecialCaseList.htmlbut it prevents fuzzing and building
--with-memory-sanitizer.Hmm, that's awkward. Is there no way to annotate to tell the sanitiser that this case has been checked and deemed safe? E.g., something like this: https://clang.llvm.org/docs/SanitizerSpecialCaseList.html
Slowing down a hot path by adding an unnecessary extra step just so that a tool doesn't emit a false positive error doesn't seem like the right solution.
- added a commit that references this issue
on Mar 20, 2023 Hmm, that's awkward. Is there no way to annotate to tell the sanitiser that this case has been checked and deemed safe? E.g., something like this: https://clang.llvm.org/docs/SanitizerSpecialCaseList.html
Yes, ignoring is an option, I mentioned it in my previous comment 🙂
#102838, I checked and it looks to fix
python infra/helper.py reproduce cpython3 fuzz_builtin_unicode clusterfuzz-testcase-minimized-fuzz_builtin_unicode-6313066228219904.- added a commit that references this issue
on May 17, 2023 The C spec says that an uninitialized value can include trap values, so in theory multiplying by zero could trap.
That won't happen on any mainstream hardware, but we should probably fix it.Reacted by Gregory P. Smith- added a commit that references this issue
on Jul 28, 2023 @markshannon could you please check if #102510 is an acceptable fix?
- added a commit that references this issue
on Jul 31, 2023 I'm closing this issue because the fix has been verified by ClusterFuzz. Thanks everyone involved!
There is a bug disclosed by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51574.
I can reproduce it by running
CC=clang ./configure --with-memory-sanitizer && make -j12.Linked PRs
ob_digitof_PyLongValue#102510ob_digitof_PyLongValue(GH-102510) #107464