-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix *** buffer overflow detected *** problem with gcc-13+ or -D_FORTIFY_SOURCE=3 #1907
Conversation
这里不可以把 memcpy 改为变量赋值。因为这里计算出来的地址未必是对齐的,对不对齐的地址写数据,并非所有平台都是正确的。 另外,如果你用的平台 skynet 这里的代码使用的是 |
我试了一下上面的 test.c ,在我的系统上并没有报告错。
|
我这边出错的平台是 WSL2 下的 Ubuntu 20.04 和 Ubuntu 24.04, 上面这个正常运行的结果是在 win 上试出来的吗, 看起来 malloc_usable_size 返回的大小是 32 和 malloc 时传入的大小时一致的所以没有导致报错吧, 我这边 alloc(32) 再 malloc_usable_size 拿到的 size 是 40 补充一下相关材料: https://bugs.launchpad.net/ubuntu/+source/gcc-13/+bug/2012440 |
单从 skynet 内看的话这边应该都是内存对齐的, 不过可能外部调用就没有保障了? 感觉比较合理的改法应该是不依赖 je_malloc_usable_size, 像这个函数名 fill_perfix 描述的那样把 handle 填到头部去, 不过也不好处理这么改之后导致的内存对齐问题... 或者我这里可以先加个 volatile 避免编译器的优化 |
我在 manjaro 上。而且 而且 如果这个 |
我不清楚你是怎么弄出这个问题出来的,实际上这里 skynet 改写了 malloc ,是自己的实现,理论上不应该受 libc 的检查约束。因为这块内存本身就不是由 libc 直接管理的。 而你如果想直接用 CRT 的 malloc ,那么应该定义宏 所以,我怀疑你是在编译链接环节出了问题,导致链接了多份不同的 malloc 。 |
我看 man 上写
我想想怎么去掉。 |
看看是不是改好了。 |
skynet_calloc 里 fill_prefix 的第二个参数应该是 (nmemb + cookie_n) * size 吧 BTW, update_xmalloc_stat_alloc 和 update_xmalloc_stat_free 是不是还用 je_malloc_usable_size 统计会比较好? |
6a7043c 已改。 我觉得完全去掉 |
不应该是 fill_prefix(ptr, n * size, cookie_n * size) 吗 @_@ |
对。抱歉,在写别的程序,刚才没仔细看。 |
gcc-13 及以上版本会默认开启 -D_FORTIFY_SOURCE=3 (原配置为 -D_FORTIFY_SOURCE=2), 在开启 O1 以上编译优化的时候编译器可能对 memcpy 插入检查, 发生越界误判 (malloc_usable_size(ptr) 返回的大小要大于实际 malloc 大小)
崩溃堆栈:
最小复现代码:
编译方式:
或者
相关: https://bugs.launchpad.net/ubuntu/+source/gcc-13/+bug/2012440