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.

[illia-v]

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.

[markshannon]

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.

[illia-v]

@markshannon could you please check if #102510 is an acceptable fix?

[illia-v]

I'm closing this issue because the fix has been verified by ClusterFuzz. Thanks everyone involved!