dlmalloc 2.8.6 源码详解—[6]调试分析

分析堆溢出漏洞不能仅仅停留在了解dlmalloc堆分配器运行原理，还需要通过调试器观察其运行过程并在堆内存中识别堆的数据结构，这就像实习医生学习做手术一样，最终检验还是要在手术台上。

1 调试代码

#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<malloc.h>
#include<unistd.h>

void func_malloc()
{
    int *p1 , *p2 , *p3 , *p4 , *p5;
    p1 = (int *)malloc(sizeof(int) * 3);
    p2 = (int *)malloc(sizeof(int) * 5);
    p3 = (int *)malloc(sizeof(int) * 6);
    p4 = (int *)malloc(sizeof(int) * 8);
    p5 = (int *)malloc(sizeof(int) * 24);

    free(p1);
    free(p2);
    free(p3);
    free(p4);
    free(p5);
}

int main(int argc,char *argv[])
{
    write(STDOUT_FILENO, "Hello, World\n", 13);
    char buf[256];
    read(STDIN_FILENO, buf, 128);
    func_malloc();
}

编译后推送到调试设备中就可以进行调试了，具体步骤可以参考搭建Android系统C程序调试环境。

2 堆的分配

2.1 初始化

首先，dlmalloc在初始状态下，整个内存空间中没有任何可用的chunk，可以通过查看mspace验证：

---

可以看到smallbins、treebins、dv和top都未分配可用的chunk，故第一次分配时，dlmalloc需要调用sys_alloc向系统申请内存（在初始化状态下第一次申请大小为对齐后的申请大小+ SYS_ALLOC_PADDING）用于后续堆分配使用，新申请的内存大小保存在top中，这就像零售商第一次进货一样，比如烟是按条进货的，后面可以在出售时可以按盒进行零售。

这里看下第一次分配，

p1 = (int *)malloc(sizeof(int) * 3);

由于此时dlmalloc处于初始状态，dlmalloc的ensure_initialization()宏会初始化并第一次向系统申请可用的堆内存，所以当初始化完毕后，dlmalloc的mspace：

此时，smallbins、treebins和dv仍没有可用的chunk，只有top被分配了初始化时向系统申请的内存用于chunk申请。

2.2 对齐

dlmalloc会对用户申请的堆内存大小进行对齐，对齐的规则是：

申请大小 + 4(chunkhead)，计算的结果向8的倍数对齐

例如，这里申请13个字节，则实际分配的堆大小为24(13+4对齐到24)字节。

第一次分配调用的对齐代码和结果：

2.3 分配

先来回顾一下small request（< 256字节）堆空间的流程：

第一次分配的逻辑很简单。由于此时只有top可以申请chunk，所以dlmalloc只是简单的从top中分割出对齐后大小的chunk，对应的代码逻辑如下：

可以通过查看top的size和返回给用户的堆地址进行验证：

topsize = 4032（初始化） – 16（对齐后的申请大小）

mem = 0x7d5018 + 8（head + 交叉检验项）

2.4 识别

dlmalloc已分配chunk的结构图如下：

所以，从第一次分配的堆内存中可以找到chunk结构，

其中黄色框是chunk的head，蓝色框就是分配给用户使用的堆内存空间。再看下head，

后两位是C位和P位，所以chunk的大小就是10000即16字节，符合预期。

2.5 小结

后续的几次分配和第一次分配逻辑基本一致，都是直接在top上进行分割。从上述的调试过程中，可以得到一些小的结论：

1. 用户申请的堆空间大小和实际获得的大小可能并不相同，实际要按对其规则计算，计算规则：

实际大小 = 8的倍数对齐(申请大小 + 4) – 4

PS：超出部分尽量不要使用以免程序不可移植。

1. 初始状态下，small bins、tree bins快表都未分配可用的chunk，申请空间请求并没有查询这两个快表，直接在top中进行分割。

3 堆的释放

同样先来回顾一下释放堆空间的流程：

3.1 释放

第一次dlfree和分配时一样很简单，由于是第一个chunk并且后一个chunk是已分配状态所以直接插入到快表中即可。来通过调试验证一下结果：

首先，根据传入的堆指针得到对应的chunk指针：

最终调用插入快表宏：

在执行插入快表前msapce的状态，

插入后mspace的状态，

其中smallmap是快表中可用chunk的位图结构，由于当前刚刚释放的chunk是16字节分箱中第一个记录，所以chunk的fd和bk都指向自身，至于为什么是索引6和7可以回顾下快表(分箱bins)的设计。

3.2 合并

再来看下第二次释放。此时前一个chunk是刚刚释放的chunk，所以会和前一个chunk进行合并，并从快表中unlink前一个chunk。

我们看到合并后新的chunk地址会前移指向前一个chunk的地址。对比第一次释放的mspace结构，来看下此时的mspace：

此时，由于前一个chunk已经从快表中unlink，所以快表中没有任何可用的chunk，smallmap的值变成0，而且索引6和7位置的fd、bk值并没有改变，说明快表的申请和删除完全由位图smallmap决定。

最后，把合并后的chunk link到快表中，

同样来看下mspace结构的变化：

后面第3、4次释放的过程和第2次相同，只有最后一次释放有些区别，因为最后一次释放时，下一个 chunk是free chunk并且是top，所以会和下一个chunk合并，并更新top为合并后的chunk指针地址，具体过程不再贴图，这里只看下最终的mspace结构变化：

最终mspace的结构应该和dlmalloc初始化（2.1小结）时是一致的，但我们还是能从快表中看到前4次释放的痕迹。

PS：之所以本文中最终的mspace和初始化时不一致，是因为分配和释放的调试分成两次进行的。