summaryrefslogtreecommitdiff
path: root/testing/resources/bug_620428.pdf
diff options
context:
space:
mode:
authorTom Sepez <tsepez@chromium.org>2017-02-24 15:31:12 -0800
committerChromium commit bot <commit-bot@chromium.org>2017-02-27 18:57:39 +0000
commitc5a1472ec5a809ff524c8888ac5884498801d06f (patch)
tree0097a8358dd5954fb48f4b2a48ea921a22a300ca /testing/resources/bug_620428.pdf
parent73c9f3bb3d82563d6d4496c4b0204d5c0825e8a2 (diff)
downloadpdfium-c5a1472ec5a809ff524c8888ac5884498801d06f.tar.xz
Fix uninitialized memory read in CJS_Object::GetEmbedObject()
The expected way to create native PDFium objects for JS is via the NewFxDynamicObject() call in C++, but that doesn't mean that the corresponding constructors won't be called from JS. In that case, the internal fields will be uninitialized, and subsequent method calls may try to use them. Add a constructor callback for all PDFium objects that nulls out these fields (shame that v8 doesn't do this by default, but probably saves some cycles). Then ensure that we check for this possibility in all the places it might turn up. Conversely, if we've just gotten a successful return from NewFxDynamicObject(), we know the CJS_Object/EmbedObj are good, so avoid checking there. BUG=695826 Change-Id: Iadad644c4af937def967ddc83daac1dad7544d69 Reviewed-on: https://pdfium-review.googlesource.com/2839 Reviewed-by: dsinclair <dsinclair@chromium.org> Commit-Queue: Tom Sepez <tsepez@chromium.org>
Diffstat (limited to 'testing/resources/bug_620428.pdf')
0 files changed, 0 insertions, 0 deletions