free 完再 malloc 一样大小，为什么常拿回刚还回去的那块？

上一篇《一次 malloc。到底是问谁要的内存》我们跟着三行 C 把堆挖到了底：malloc 先翻 libc 自己的池子、池子空了才向内核批发、内核给的还是张“空头支票”，直到第一次写才配上物理页。留了个钩子——free 之后那块地并不会消失。“地还在只是主人随时会换”，并说这就是 use‑after‑free 危险的物理根源。这一篇就来兑现：主人到底怎么换、为什么换得那么有规律顺带把 use‑after‑free 为什么是个能被武器化的重磅漏洞讲透。

使用者痛点： 很多人调试程序时会发现，/usr/bin/your_app …在打印同一地址两次后却只看到一次崩溃；又或者在做“双重释放”测试时突然出现奇怪的数据。原因往往是上述现象——false‑reuse 与 LIFO-style 分配器行为。怎么说呢，

实验环境与代码复现

The following minimal program reproduces phenomenon on x86‑64 glibc:

#include 
#include 
int main
{
int *p = malloc;// request 32 bytes
printfp);*p) = 'A'，// touch it
free;其实，int *q = malloc;// same size again
printfq);return 0，按理说，}

You can compile and run it like this:

gcc -O0 -g -o exp exp.c
./exp

A typical output looks like this:

第一次拿到: 0x55e5a1c1b260
free 后再拿到: 0x55e5a1c1b260 <== 同一块!

The two allocations return exact same address every time—no matter how many times you rerun program—thanks to glibc’s deterministic allocation strategy.

一、先把现象钉死：LIFO 行为

If you allocate three blocks sequentially and n free m in same order。followed by anor three allocations,you’ll see that addresses come back in reverse order:

int *a = malloc,*b = malloc,*c = malloc;printf，free;free，free;int *x = malloc。*y = malloc,*z = malloc;printf，

A typical run shows:

分配 a=0x55e5a1c1b200 b=0x55e5a1c1b220 c=0x55e5a1c1b240
分配 x=0x55e5a1c1b240 y=0x55e5a1c1b220 z=0x55e5a1c1b200

• The last freed block ) is returned first.
• The first freed block ) is returned last.
• This is classic LIFO—last-in first-out.
• No randomization or search happens here.
• The behaviour is fully deterministic and repeatable.
• This explains *** “ same size after free often returns exactly old address.” – it’s simply at top of its bucket’s stack.
• This property also gives performance benefits by keeping recently used chunks hot in CPU caches.
• The mechanism exists across all modern glibc versions that support tcache or fastbin.
• A quick visualisation shows *** freeing pushes onto head of a linked list while allocating pops from it.
• If you ever wonder *** your program “seems lucky” when reallocating freed memory。it’s because of this very rule.
• If you need more evidence,try freeing many more blocks than fit into tcache and observe that y spill over into fastbin but still maintain LIFO order per bucket.
• This deterministic behaviour underpins both performance optimisations and security weaknesses alike.
⚠️ **注意**：若你使用的是旧版 glibc，没有 tcache 层，而所有小块直接进入 fastbin 或 unsorted bin；但 fastbin 本身仍然采用 LIFO。所以实验结果基本相同，只是链表结构略有差别。

二、空闲仓库不是一个大筐，而是一排按大小划分的链表

先搞清楚“大小”指的是哪种尺寸

• A chunk contains:
  • A header that stores its own size and wher preceding chunk was used;
  • An alignment boundary – on x86‑64 each chunk must be multiple of 16 bytes;
  • A minimum chunk size – typically 48 bytes even if you request fewer bytes;

The requested size is **not** what determines which bucket it lands in;instead it’s computed chunk size that matters. For example:

• If you request e.g.。24 bytes,libC rounds up to a chunk of 48 bytes due to alignment and minimum-size rules;
• You’ll always land in same bucket until your request grows large enough that rounded size jumps to next bucket boundary;按理说，
• This means two different requests can share exactly one bucket if ir rounded sizes coincide;
💡 **示例**：请求 31 字节 → round up to 48 字节 → 跳到第 n 个桶；请求 65 字节 → round up to 80 字节 → 第 n+ k 个桶。

至于桶如何排布，等差间隔。一个桶对应一个固定区间尺寸

• Tcache 有固定数量个桶，对应从最小 chunk 开始每隔16字节一个桶；例如：

• Tcache holds only small chunks up to ~512 B . Each class has its own singly linked list of available chunks;说起来，
🔧 **fastbin** 的作用：
• Fastbin 是 Tcache 满后多出的同类空闲块；它们也用单向链表，但不是线程私有，需要加锁；其覆盖面比 Tcache 窄得多，仅限于最小几档。• Fastbin 和 unsorted/small bins 都保持 LIFO 顺序。尽管它们更慢，但对性能影响极小。• 如果你想观察更多细节，可以开启 `GLI娱乐_TUNABLES=tcache:true` 并使用 `LD_PRELOAD=/lib/x86_64-linux-gnu/libtcmalloc.so` 等工具查看内部结构。老实说，• 对于大块，glibc 会把它们放进 unsorted bin 或者按更粗粒度划分的小 bin。而不是 tcache/fastbin。
⚠️ 对不同 glibc 版本。这些数字和阈值可能略有变动，例如某些旧版不支持 tcache；但主要思想保持一致，不过，

三、关键机关：`next` 指针被写入你原本的数据区里！**