tsepez@, can you please help to find an owner?

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Duplicate of  bug 654272 ?

I can't seem to get this to report an error even when I reset my PDFium back to the same commit.

Looking at the clusterfuzz page, it seems like something is weird as the two stacktraces given are very different?

mmoroz@ is it possible to get clusterfuzz to check if this is still happening and, if so, to get a recent stacktrace?

I'll give this a whirl too...

Repros at ToT for me. I have MSAN set up in a Chromium checkout, where I just pulled in third_party/pdfium.

My GN config is:

is_component_build = false
is_debug = false
is_msan = true
msan_track_origins = 2
use_goma = true
use_prebuilt_instrumented_libraries = true

and I followed the instructions on the Chromium MSAN page.

After I built pdfium_test, I ran:

MSAN_OPTIONS="detect_leaks=1 symbolize=1 external_symbolizer_path=/path/to/chrome/src/third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer" ./out/msan/pdfium_test /tmp/b655543.pdf

Still doesn't repro for me. Updated my msan args to, mostly, match yours as I didn't have the prebuilt binaries bit or msan_track_origins. But, still no luck.  Can you post the stack you get I'd like to see how it matches up to the clusterfuzz stacks.



Development/chromium/src % MSAN_OPTIONS="detect_leaks=1 symbolize=1 external_symbolizer_path=$PWD/third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer" ./out/msan/pdfium_test ~/Downloads/fuzz-51.pdf   
Rendering PDF file ~Downloads/fuzz-51.pdf.
Rendered 3 pages.

Development/chromium/src % cat out/msan/args.gn                                                                                                                                          [master] 
# Build arguments go here. Examples:
#   is_component_build = true
#   is_debug = false
# See "gn args <out_dir> --list" for available build arguments.

use_goma = true

is_clang = true
is_msan = true
msan_track_origins = 2
is_asan = false
is_lsan = false

use_libfuzzer = true
use_prebuilt_instrumented_libraries = true

is_debug = false
is_component_build = false

dcheck_always_on = true

symbol_level = 1

enable_nacl = false
remove_webcore_debug_symbols = true

Using https://pdfium.googlesource.com/pdfium/+/a282c7380f3964de41ea93c9980b12c4513d3473

==101129==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x337b229 in __root buildtools/third_party/libc++/trunk/include/__tree:880:65
    #1 0x337b229 in find<const CPDF_Dictionary *> buildtools/third_party/libc++/trunk/include/__tree:2028
    #2 0x337b229 in find buildtools/third_party/libc++/trunk/include/map:1253
    #3 0x337b229 in CPDF_InterForm::GetControlByDict(CPDF_Dictionary const*) const third_party/pdfium/core/fpdfdoc/cpdf_interform.cpp:939
    #4 0x30aa18d in CPDFSDK_WidgetHandler::ReleaseAnnot(CPDFSDK_Annot*) third_party/pdfium/fpdfsdk/cpdfsdk_widgethandler.cpp:87:41
    #5 0x305bd94 in CPDFSDK_PageView::~CPDFSDK_PageView() third_party/pdfium/fpdfsdk/cpdfsdk_pageview.cpp:71:23
    #6 0x304ee9f in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #7 0x304ee9f in reset buildtools/third_party/libc++/trunk/include/memory:2735
    #8 0x304ee9f in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2703
    #9 0x304ee9f in ~pair buildtools/third_party/libc++/trunk/include/utility:280
    #10 0x304ee9f in ~__value_type buildtools/third_party/libc++/trunk/include/map:653
    #11 0x304ee9f in __destroy<std::__1::__value_type<CPDF_Page *, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > > > buildtools/third_party/libc++/trunk/include/memory:1673
    #12 0x304ee9f in destroy<std::__1::__value_type<CPDF_Page *, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > > > buildtools/third_party/libc++/trunk/include/memory:1536
    #13 0x304ee9f in std::__1::__tree<std::__1::__value_type<CPDF_Page*, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > >, std::__1::__map_value_compare<CPDF_Page*, std::__1::__value_type<CPDF_Page*, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > >, std::__1::less<CPDF_Page*>, true>, std::__1::allocator<std::__1::__value_type<CPDF_Page*, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > > > >::destroy(std::__1::__tree_node<std::__1::__value_type<CPDF_Page*, std::__1::unique_ptr<CPDFSDK_PageView, std::__1::default_delete<CPDFSDK_PageView> > >, void*>*) buildtools/third_party/libc++/trunk/include/__tree:1431
    #14 0x3047216 in ~__tree buildtools/third_party/libc++/trunk/include/__tree:1419:5
    #15 0x3047216 in ~map buildtools/third_party/libc++/trunk/include/__tree:1105
    #16 0x3047216 in CPDFSDK_FormFillEnvironment::~CPDFSDK_FormFillEnvironment() third_party/pdfium/fpdfsdk/cpdfsdk_formfillenvironment.cpp:68
    #17 0x303b524 in FPDFDOC_ExitFormFillEnvironment third_party/pdfium/fpdfsdk/fpdfformfill.cpp:287:3
    #18 0x49beb7 in RenderPdf(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char const*, unsigned long, Options const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) third_party/pdfium/samples/pdfium_test.cc:802:3
    #19 0x49dffb in main third_party/pdfium/samples/pdfium_test.cc:928:5
    #20 0x7fbb61cc7f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
    #21 0x4236bc in _start (/usr/local/google/home/thestig/chrome2.git/src/out/cros_msan/pdfium_test+0x4236bc)

  Uninitialized value was created by a heap deallocation
    #0 0x48dc52 in operator delete(void*) (/usr/local/google/home/thestig/chrome2.git/src/out/cros_msan/pdfium_test+0x48dc52)
    #1 0x30471d7 in operator() buildtools/third_party/libc++/trunk/include/memory:2529:13
    #2 0x30471d7 in reset buildtools/third_party/libc++/trunk/include/memory:2735
    #3 0x30471d7 in ~unique_ptr buildtools/third_party/libc++/trunk/include/memory:2703
    #4 0x30471d7 in CPDFSDK_FormFillEnvironment::~CPDFSDK_FormFillEnvironment() third_party/pdfium/fpdfsdk/cpdfsdk_formfillenvironment.cpp:68
    #5 0x303b524 in FPDFDOC_ExitFormFillEnvironment third_party/pdfium/fpdfsdk/fpdfformfill.cpp:287:3
    #6 0x49beb7 in RenderPdf(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char const*, unsigned long, Options const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) third_party/pdfium/samples/pdfium_test.cc:802:3
    #7 0x49dffb in main third_party/pdfium/samples/pdfium_test.cc:928:5
    #8 0x7fbb61cc7f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287

This seems like a different issue? This is CPDF_InterForm::GetControlByDict, not KillTimer. 

   const auto it = m_ControlMap.find(pWidgetDict);

m_ControlMap is a class variable, so pWidgetDict is uninitialized?

Maybe, need to take a closer look. Also note in a regular debug build, pdfium_test crashes for this PDF file.

BTW "Uninitialized value was created by a heap deallocation" makes me think ASAN should have picked this up. Maybe it needs its options tweaked. e.g. bigger red zone of something.

Using good old Valgrind in a standalone checkout, there's no crash with XFA enabled. Without XFA, it shows:

Invalid read of size 8
  at 0xDC4595: std::unique_ptr<CPDF_InterForm, std::default_delete<CPDF_InterForm> >::get() const (in out/gnnoxfa/pdfium_test)
  by 0xDC4478: CPDFSDK_InterForm::GetInterForm() const (in out/gnnoxfa/pdfium_test)
  by 0xDDC2BF: CPDFSDK_Widget::GetFormControl() const (cpdfsdk_widget.cpp:535)
...
  by 0xDC82AE: std::__debug::map<CPDF_Page*, std::unique_ptr<CPDFSDK_PageView, std::default_delete<CPDFSDK_PageView> >, std::less<CPDF_Page*>, std::allocator<std::pair<CPDF_Page* const, std::unique_ptr<CPDFSDK_PageView, std::default_delete<CPDFSDK_PageView> > > > >::~map() (in /usr/local/google/home/thestig/pdfium/pdfium/out/gnnoxfa/pdfium_test)==    by 0xDC5C30: CPDFSDK_FormFillEnvironment::~CPDFSDK_FormFillEnvironment() (cpdfsdk_formfillenvironment.cpp:68)

Address 0x6a75510 is 16 bytes inside a block of size 160 free'd
  at 0x4C2DEE8: operator delete(void*) (vg_replace_malloc.c:479)
  by 0xDCEB51: CPDFSDK_InterForm::~CPDFSDK_InterForm() (cpdfsdk_interform.cpp:63)
  by 0xDB517E: std::default_delete<CPDF_Font>::operator()(CPDF_Font*) const (unique_ptr.h:67)
  by 0xDC8262: std::unique_ptr<CPDFSDK_InterForm, std::default_delete<CPDFSDK_InterForm> >::~unique_ptr() (unique_ptr.h:184)
  by 0xDC5C20: CPDFSDK_FormFillEnvironment::~CPDFSDK_FormFillEnvironment() (cpdfsdk_formfillenvironment.cpp:68)
  by 0xDB9F83: FPDFDOC_ExitFormFillEnvironment (fpdfformfill.cpp:287)

This is an MSAN report, not ASAN. 
MSAN does not have readzones or quarantine so when there is a use-after-free
or a buffer overflow it may produce ahrd-to-understand reports. 

I am pretty sure asan will give report similar to valgrind's

and surely it does:

==21317==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000000520 at pc 0x000000572b56 bp 0x7ffcde17b5d0 sp 0x7ffcde17b5c8
READ of size 8 at 0x60b000000520 thread T0
    #0 0x572b55 in get buildtools/third_party/libc++/trunk/include/memory:2714:76
    #1 0x572b55 in CPDFSDK_InterForm::GetInterForm() const third_party/pdfium/fpdfsdk/cpdfsdk_interform.h:36
    #2 0x5bd560 in CPDFSDK_Widget::GetFormControl() const third_party/pdfium/fpdfsdk/cpdfsdk_widget.cpp:535:49
    #3 0x62a361 in CPDFSDK_WidgetHandler::ReleaseAnnot(CPDFSDK_Annot*) third_party/pdfium/fpdfsdk/cpdfsdk_widgethandler.cpp:87:41
    #4 0x5f2b07 in CPDFSDK_AnnotHandlerMgr::ReleaseAnnot(CPDFSDK_Annot*) third_party/pdfium/fpdfsdk/cpdfsdk_annothandlermgr.cpp:58:18
    #5 0x5b0829 in CPDFSDK_PageView::~CPDFSDK_PageView() third_party/pdfium/fpdfsdk/cpdfsdk_pageview.cpp:71:23
...


previously allocated by thread T0 here:
    #0 0x4f20db in operator new(unsigned long) (/usr/local/google/home/kcc/chromium/src/out/libfuzzer/pdfium_test+0x4f20db)
    #1 0x58952b in pdfium::internal::MakeUniqueResult<CPDFSDK_InterForm>::Scalar pdfium::MakeUnique<CPDFSDK_InterForm, CPDFSDK_FormFillEnvironment*>(CPDFSDK_FormFillEnvironment*&&) third_party/pdfium/third_party/base/ptr_util.h:56:29
    #2 0x585dce in CPDFSDK_FormFillEnvironment::GetInterForm() third_party/pdfium/fpdfsdk/cpdfsdk_formfillenvironment.cpp:691:20
    #3 0x54da36 in (anonymous namespace)::FormHandleToInterForm(void*) third_party/pdfium/fpdfsdk/fpdfformfill.cpp:48:39
    #4 0x54d902 in FPDF_SetFormFieldHighlightColor third_party/pdfium/fpdfsdk/fpdfformfill.cpp:639:39

Weird, why didn't ASAN work for me here?

https://pdfium.googlesource.com/pdfium/+/2116105b7d0545eb353264d4b42420cf51af5195 initially caused the crash with the KillTimer stack trace. That's what CF is complaing about here. That's actually  bug 654272 .

When  bug 654272  got fixed with https://pdfium.googlesource.com/pdfium/+/709f5a9301e91365ab87610993c497e386504ead, it stopped crashing.

But I was lazy and just synced to ToT, and it's crashing again at ToT. That bisected to https://pdfium.googlesource.com/pdfium/+/6c659ab22988716c0f578460a2048663ab93805a so it still goes to dsinclair.

ClusterFuzz has detected this issue as fixed in range 424153:424926.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4765511814742016

Fuzzer: ifratric_pdf_generic
Job Type: linux_msan_pdfium
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  CPDFSDK_FormFillEnvironment::KillTimer
  CPWL_TimerHandler::EndTimer
  CPWL_Caret::SetCaret
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_pdfium&range=423265:423386
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_pdfium&range=424153:424926

Minimized Testcase (5557.11 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97H-mrmBFwtYlpCsmR8mUMP-y6wqGyuBXSKePPZtHkqskTrNljF-_RJlB7ZyTx1pu9UB44DuHMRSeQ1XD1XOphkNF5-Sz62rhO33zMlNvtd58uQYA395Ktta2io1GVwlAmY0A5p8F7zclv7RQa6xVkoXF-Oqjay8EmleDzecE4htUzpYGU?testcase_id=4765511814742016

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I'm setting High severity since it revealed to be a use-after-free. Has it been fixed or is ClusterFuzz wrong?

If it has been fixed in M56, we need to identify what to merge to M55.

This looks like a dupe of 654272 which has already been merged.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot