这个漏洞发生在 MaglevGraphBuilder::VisitFindNonDefaultConstructorOrConstruct 函数中，考虑之前分析的 CVE-2023-4069 也是发生在该函数中，所以打算把该漏洞也分析了。该漏洞主要发生在折叠分配时，未考虑内存空间分配与初始化之间的操作可能导致触发 gc，从而导致 UAF

还是从 patch 入手：

可以看到补丁代码非常简单，就是添加了个 ClearCurrentRawAllocation 函数：

该函数的功能为将 current_raw_allocation_ 指针清空

这里补丁代码打在了 TryBuildFindNonDefaultConstructorOrConstruct 函数中，其上层调用链为：

而 VisitFindNonDefaultConstructorOrConstruct 其实我们在之前分析 CVE-2023-4069 时就详细分析过，其主要就是处理 FindNonDefaultConstructorOrConstruct 节点的，但是这里还是放一下代码分析吧：

这里会先调用 TryBuildFindNonDefaultConstructorOrConstruct 尝试进行图创建：

可以看到这里我们可以将其分为快速路径和慢速路径，快速路径主要就是利用 new_target.initial 直接进行对象创建，慢速路径则退回到内建函数 FastNewObject，这里我们主要看快速路径，快速路径为 【1】->【2】->【3】，而 【3】 也是漏洞代码所在处，所以需要满足以下条件：

这里想要到达想要到达漏洞逻辑，得绕过这三个判断，前面两个还是之前的方式插入 CheckValue 节点绕过，第三个就不多说了，new_target 是派生构造函数即可，或者顶层默认构造函数也????，比较简单

最后为分配对象的语句如下，也是漏洞代码所在处：

然后跟进 BuildAllocateFastObject，看其是如何创建对象的：

这里可以看到分配空间调用了 ExtendOrReallocateCurrentRawAllocation 函数，其会尝试折叠分配：

先来说下什么是折叠分配？顾名思义，当我们在进行内存分配时，可能每次分配一小块内存，比如下面场景：

而多次分配内存可能是一个比较耗时的行为，于是编译器在静态分析阶段，会尝试进行分配折叠优化：

这里就避免了多次内存分配，但在动态类型语言中，可能会出现一些问题，比如在 JavaScript 中，内存是由 gc 进行管理的，在 V8 中，没有被 root object 直接或间接引用的对象被标记为死对象，在触发 gc 时会被回收。所以考虑如下场景：

而如果此时发生分配折叠优化：

这里的问题就是在分配完空间后，只对 obj1 的部分进行了初始化，而 obj2 的初始化则是在后面，那么如果在初始化 obj2 之前触发了 gc，那么此时 current_raw_allocation_+0x10 这后面的内存就会被回收掉，如果我们此时分配对象占据这块内存，后面 do something2 时，仍然使用 current_raw_allocation_+0x10，则导致 UAF

让我们回到该漏洞分析中，通过上面的分析我们可以知道：

poc 如下：

这里先来看下 Maglev IR：

调试分析下：

this 对象的地址为 0x2bca002ba4d5，instance_size = 12，与 Maglev IR 图是吻合的：

然后程序就 crash 了：

从调用栈中的函数名称可以知道，明显触发了 gc，而这里 rsi 的值为一个 --- 地址，所以发生内存访问错误。这里我们来看下 this 对象下方的内存：

这里我们换个角度看：0x2bca002ba4d5-1 = this_addr ==> o_addr = this_addr+12

看到这里其实就明白了，最开始分配了 84 字节的空间，减去 this 对象占据的头 12 字节的空间，还剩下 72 字节的空间，这 72 字节其实就是包含了 o 对象本身的空间和其 elements 占据的空间

而这段空间在 o 对象初始化之前在 gc 的过程中被释放了，然后又被其它对象占据了，所以在 o 初始化这段空间时就发生了 UAF，即把其它对象内容给覆盖了，所以后面的 rsi 为 0x2bca3ff19999 = 0x2bca00000000 + 0x3ff19999，这里的 0x3ff19999 就是 1.1 的头 4 字节

嗯，，，笔者感觉这个漏洞想要稳定利用还是比较困难的，因为我们无法精准控制 gc，并且也无法精确控制释放后的内存被哪个对象占据。后面看看别人的 expliot 吧，主要是这里的 gc 搞得我很烦，还是太菜了~~~
======================== 后续 ================================
写利用写了两天，但是还是没写出来，gc 后似乎拿不到指定的内存，主要是 victim 始终在 this 对象的上方，不知道为啥，看参考文章说其应该在下方~~~太菜了，然后不想在继续浪费时间了，后面有灵感了在回来写利用，暂时留个坑

失败的 exploit：

如有读者能够写出稳定的利用，希望不吝赐教
================================== 更新 ===================
最后根据公开的 exp 并与 toka ✌一起写出了 exploit：

通过分析该漏洞，学习到了分配折叠优化，目前已经通过复现漏洞学习了编译的如下常见优化方式：

总的来说还是不错的，弥补了自己对编译器知识的匮乏，希望后面能够学到更多有趣的编译器漏洞

Google Chrome V8 CVE-2024-0517 Out-of-Bounds Write Code Execution

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)