memcpy memmove GLIBC_2.14/2.2.5的说明

Question

我的问题源于我给出的共享库,没有重新编译库的选项.错误说明undefined reference to memcpy@GLIBC_2.14.

我机器上的GLIBC版本是2.12.我见过人们使用该线路在线完成的修复工作

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

我做的修复是使用十六进制编辑器将2.14的引用更改为GLIBC_2.2.5.执行命令时readelf -V lib_name.so,输出更改为:

0x0060  Name: GLIBC_2.14 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

至:

0x0060  Name: GLIBC_2.2.5 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

这解决了我的错误.我想知道的是它会产生什么样的影响.我曾尝试研究的memcpy对比的memmove与memcpy的在GLIBC_2.14开始的变更,但我不太明白是怎么回事,什么原问题的memcpy了.我担心这个"修复",虽然它允许我的程序运行,以防memcpy正在做的事情表现不正常.为什么我在网上看到的所有修复程序都专门链接到2.2.5版本？

如果有人能给我一些关于这个主题的见解或提供一些相关信息的链接,我将不胜感激.

Answer 1

我想知道的是它会产生什么样的影响.

最可能的影响是,第三方库第一次调用时memcpy,会崩溃.

引入新版本是有原因的memcpy@GLIBC_2.14:它与旧版本不兼容memcpy(这里发生的事情是GLIBC-2.14,memcpy是一个GNU_IFUNC,这意味着它返回实际的地址memcpy;第三方库中的代码然后将调用返回的例程.但返回值memcpy@GLIBC_2.2.5是目标参数而不是函数地址,因此您应该立即崩溃).

如果有人能给我一些见解

您获得的图书馆需要 GLIBC-2.14.通过在GLIBC-2.12机器上运行它,您已经取消了所有保修.你最好的选择是:

• 与第三方供应商合作,以获得与您的执行环境兼容的库版本,或
• 使您的执行环境与您给出的库兼容(即更新您的操作系统).你或许应该这样做反正让你的系统无法通过最近的漏洞,比如被荷兰理智人士之类公共广播CVE-2015-7547.