diff options
author | Tom Sepez <tsepez@chromium.org> | 2017-02-27 11:43:55 -0800 |
---|---|---|
committer | Chromium commit bot <commit-bot@chromium.org> | 2017-02-27 20:24:33 +0000 |
commit | 3f72fb4a3c983de00bae9c8437a1c09df9c9955b (patch) | |
tree | 64d73f9b0448952e714eb71ea8483eef628acdd5 /third_party/libtiff/0001-build-config.patch | |
parent | 9162ff85c323b05e3280b319a388934e871e4aea (diff) | |
download | pdfium-3f72fb4a3c983de00bae9c8437a1c09df9c9955b.tar.xz |
Explicitly tag fxjs native objects.
Native object callbacks have to distinguish whether the object
they have been given is actually a native object and not some
ordinary JS object. For method/property calls, this happens
via v8's signature mechanism, but signature checks aren't applied
to method arguments themselves.
Currently, we do this by treating any object with an internal field
count of 2 as being such, but this is fragile, and it has been pointed
out that other objects with two internal fields are present.
Additionally, that the first field points to a structure with a
small zero-based object definition ID doesn't really have enough
entropy to trust that it isn't some other entity. So add a pointer
to an internal address in the second slot to make this safer.
Note that we'll also get the same release_assert in the majority
of cases as described in the bug. This is great from a security
standpoint, but not great from a functional standpoint, except this
likely only occurs in the wild if they are trying to mess with us.
This just guards the theoretical cases that might pass the
existing release_assert.
BUG=695830
Change-Id: I42db27d6ed1143269a852805e4e4d862a8ab8773
Reviewed-on: https://pdfium-review.googlesource.com/2847
Commit-Queue: Tom Sepez <tsepez@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>
Diffstat (limited to 'third_party/libtiff/0001-build-config.patch')
0 files changed, 0 insertions, 0 deletions