GlibC 在线程里引发use-after-free退出时才崩溃原因与分析

背景最近在做开发时遇到了一个错误tcache_thread_shutdown(): unaligned tcache chunk detected这个错误是发生在多线程情况下没有做好互斥时发生一个指针被free之后再次使用也就是比较经典的use-after-free的错误触发了Abort虽然不是什么大问题很容易修复但是这引发了我一个比较好奇的事情就是为什么会这样为什么free之后继续使用没报错但是线程退出时导致崩溃了原理我使用的是GCC编译器标准库是Glibc对于Glibc而言每次malloc的内存都要比预期申请的要大一点因为里面要放入一些malloc的元数据基本上malloc的内存布局是这样的[malloc chunk header][用户区64bytes]^|pp是返回给我们使用的user地址每次当我们释放时Glibc并不会把它归还给系统而是自己维护一个内存chunk把这次的Malloc内存放入一个tcache链表维护起来这样后续在使用可以从这里拿内存提高分配效率这里就有一个点就是如果没有归还给系统的话页表的映射还在当前进程上面也就是说你free之后依然可以随意访问这块地址并不会发生什么非法地址访问的情况下面是一个示例#includestdio.h#includestdlib.hintmain(void){char*pmalloc(64);if(!p){return1;}free(p);p[0]0x01;p[1]0x02;printf(hello world!\n);return0;}此时hello world会正常打印并且也不会出现任何问题这种做法与我们平时接触到的C语言教学背道而驰平常教科书上的教学是针对C语言这门语言特性而Glibc是C语言的标准实现库它有自己的行为并且在不同系统上也有不同区别但是这里我们换一种方式用线程来执行#includepthread.h#includestdio.h#includestdlib.h#includestring.h#includeunistd.hstaticvoid*worker(void*arg){char*amalloc(64);printf([worker] a%p\n,a);free(a);memset(a,0x55,64);printf([worker] corrupted freed chunk, now return\n);returnNULL;}intmain(void){pthread_ttid;if(pthread_create(tid,NULL,worker,NULL)!0){perror(pthread_create);return1;}pthread_join(tid,NULL);printf([main] worker joined\n);return0;}运行结果[worker]a0x79d9f0000b70[worker]corrupted freed chunk, nowreturntcache_thread_shutdown(): unaligned tcache chunk detected[1]29787IOT instruction(core dumped)./a.out可以看到被异常结束了是Glibc主动调用了Abort函数发送SIGABRT异常信号结束当前进程并且打印了tcache_thread_shutdown()这个原因是C语言的线程检查行为对于Main而言它虽然也是一个线程但是Glibc对它行为是它是主线程结束时Glibc调用exit来回收它与普通线程行为不同Main的链路是_start- __libc_start_main(…)- 调用main(argc, argv, envp)- main return- exit(main_return_value)- 执行 atexit/on_exit 回调- flush/close stdio- glibc 内部清理- _exit(status)- exit_group 系统调用- 内核销毁整个进程普通线程行为调用的是pthread_create()- glibc clone创建线程- 新线程从glibc 的 start_thread入口开始- start_thread 调用你的 thread_func(arg)- thread_func return- glibc 执行 pthread_exit 收尾逻辑- 清理当前线程资源- 当前线程结束注意这里调用的是pthread_exit而不是系统的exit这里它会去调用tcache_thread_shutdown来检查chunk有没有被破坏这点你可以在它的源码里面找到这里我找的是2.xmalloc/malloc.c的源码staticvoidtcache_thread_shutdown(void){……for(i0;iTCACHE_MAX_BINS;i){while(tcache_tmp-entries[i]){tcache_entry*etcache_tmp-entries[i];if(__glibc_unlikely(!aligned_OK(e)))malloc_printerr(tcache_thread_shutdown(): unaligned tcache chunk detected);tcache_tmp-entries[i]REVEAL_PTR(e-next);__libc_free(e);}}……}可以看到它在循环调用aligned_OK来检查tcache里面的指针是否被破坏的也就是判断是不是Malloc合法边界这个是看当前CPU位数64位是16字节32位是8字节用MALLOC_ALIGNMENT宏表示在不同平台位数上它的内存颗粒不同它会多分配一些字节一部分用于维护Malloc元数据一部分给用户使用在64位上即使你分配没有16个字节它仍然会将你的分配按16字节对齐如果tcache记录的地址里面有一块不是按16字节对齐的那么就会立马出错它认为当前线程破坏了tcache导致内存模型出现了问题可能引发异常错误就会直接abort在malloc_printerr里面会调用abort。因此当我们平时调试的时候不要总是依靠C语言的标准答案而是去参考具体平台和标准实现细节例如对着Glibc库源码分析原因。Main之所以没有做这层检查是因为Main结束整个应用都要结束了因此没必要在做这些事情了直接调用exit让系统一并将这个task全部清理掉因为它所有的内存数据这些都在task_struct里被记录着内核一并释放掉就可以了。