# CVE-2022-3723: Logic Issue in Turbofan JIT Compiler

Turbofan failed to generalize 'None' FieldType on kStoreInLiteral stores, letting optimized code keep stale map assumptions and build type confusion in V8.

- Payout: Real-world hack
- Severity: high
- Program: Google Chrome
- Credited: Samuel Groß, V8 Security
- Disclosed: 2022-10-27
- CVE: CVE-2022-3723
- Write-up quality: 9/10
- Original: https://github.com/googleprojectzero/0days-in-the-wild/blob/main/0day-RCAs/2022/CVE-2022-3723.md
- Library page: https://bugbountylibrary.com/r/p0%3ACVE-2022-3723
- Tags: domain:browser impact:rce kind:incident platform:project-zero sev:high tech:chromium technique:incomplete-fix technique:source-review vuln:memory-corruption

**Target:** V8 Turbofan JIT compiler (Chrome renderer)
**Root cause:** Turbofan handled the 'None' FieldType case for kStore but not kStoreInLiteral, so a store to a field whose FieldType was cleared (weak map collected) skipped generalization and did not deoptimize dependent optimized code.
**Steps:**
1. Create makeObject() building OUTER with `.inner` of type INNER having `.foo` of type Y, using `{ inner: { ['foo']: 0 } }` to force kStoreInLiteral.
2. Create setInnerProperty(o) doing `o.inner.foo = {}`; optimize it so Turbofan elides CheckMap for `.inner` via FieldType.
3. Run makeObject(), gc(), makeObject(), gc() to free INNER map while keeping OUTER map alive; FieldType of `.inner` becomes 'None' without deoptimizing setInnerProperty.
4. Optimize makeObject() and call it: kStoreInLiteral creates new OUTER with INNER whose `.foo` is type X, without generalizing FieldType.
5. Call setInnerProperty() to write X into `.foo`, now inconsistent with FieldType; access `.foo` in optimized code to get type confusion.
**How found:** Text speculates manual analysis or targeted fuzzing of 'None' FieldType handling in the JIT; fuzzers would struggle without support for computed-key literal stores like `{ ['foo']: 42 }`.
**Exploitation:** Type confusion between V8 objects in optimized code; typical flow builds arbitrary read/write primitive then achieves shellcode execution. Exploit sample existed but not shown.
**Escalation:** Type confusion -> arbitrary read/write -> shellcode execution; likely part of an exploit chain.
**Insight:** Audit JIT store paths for asymmetric handling of degenerate type states across AccessModes (kStore vs kStoreInLiteral); weak-reference-cleared FieldTypes that skip deopt are a prime spot for stale-assumption type confusion.