cpython3:fuzz_builtin_unicode: Use-of-uninitialized-value in maybe_small_long

[illia-v]

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

• gh-102509: Start initializing ob_digit of _PyLongValue #102510
• gh-102509: Ignore acceptable access of an uninitialized value #102838
• [3.12] gh-102509: Start initializing ob_digit of _PyLongValue (GH-102510) #107464

[terryjreedy]

@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'.

[illia-v]

@terryjreedy I think "Issue filed automatically" refers to the issue 51574 on https://bugs.chromium.org/p/oss-fuzz/issues/list,

[ammaraskar]

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.

[mdickinson]

See comments on the PR; I believe this is a false positive, and can safely be closed.

[mdickinson]

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.

[illia-v]

@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-sanitizer flag should let a compiler know that it is a known issue probably. https://clang.llvm.org/docs/SanitizerSpecialCaseList.html

[mdickinson]

but 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.