|
|
WebKit: Memory Corruption in TypedArray.copyWithin | ||
| Project Member Reported by natashenka@google.com, Jun 28 2016 | Back to list | ||
There is a bug in TypedArray.copyWithin that can be used to write to an absolute pointer.
In JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h, the function genericTypedArrayViewProtoFuncCopyWithin contains the following code:
long length = thisObject->length();
long to = argumentClampedIndexFromStartOrEnd(exec, 0, length);
long from = argumentClampedIndexFromStartOrEnd(exec, 1, length);
long final = argumentClampedIndexFromStartOrEnd(exec, 2, length, length);
if (final < from)
return JSValue::encode(exec->thisValue());
long count = std::min(length - std::max(to, from), final - from);
typename ViewClass::ElementType* array = thisObject->typedVector();
memmove(array + to, array + from, count * thisObject->elementSize);
argumentClampedIndexFromStartOrEnd will call valueOf on a parameter to the copyWithin function, which can contain a function that neuters the this array, causing the variable "array" to be null. However, the "to" and "from" variables can be very large values, up to 0x7fffffff, which could be valid pointers on ARM and 32-bit platforms. This allows an absolute pointer in this range to be written to.
An HTML file demonstrating this issue is attached. This issue affects Safari Technology Preview and WebKit, but has not made it into production Safari yet (TypedArray.copyWithin is not supported).
This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
Project Member
Comment 1
by
natashenka@google.com,
Jun 28 2016
,
Jul 29 2016
Fixed in Nightly. Unrestricting.
,
Sep 20 2016
|
|||
| ► Sign in to add a comment | |||