diff options
author | Tom Sepez <tsepez@chromium.org> | 2017-02-24 15:31:12 -0800 |
---|---|---|
committer | Chromium commit bot <commit-bot@chromium.org> | 2017-02-27 18:57:39 +0000 |
commit | c5a1472ec5a809ff524c8888ac5884498801d06f (patch) | |
tree | 0097a8358dd5954fb48f4b2a48ea921a22a300ca /core/fpdfapi/cpdf_modulemgr.h | |
parent | 73c9f3bb3d82563d6d4496c4b0204d5c0825e8a2 (diff) | |
download | pdfium-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 'core/fpdfapi/cpdf_modulemgr.h')
0 files changed, 0 insertions, 0 deletions