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以及从GLIBC_2.14开始对memcpy的更改，但我不太明白发生了什么以及memcpy的原始问题是什么。我担心这个“修复”，虽然它允许我的程序运行，以防memcpy正在做的事情表现不正常。为什么我在网上看到的所有修补程序都专门链接到2.2.5版本？

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

Answer 1

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

最可能的影响是，当您的第三方图书馆第一次调用memcpy时，它会崩溃。

原因引入了memcpy@GLIBC_2.14的新版本：它与旧版memcpy不兼容ABI（这里发生的是GLIBC-2.14，memcpy是GNU_IFUNC，这意味着它返回实际memcpy的地址;第三方库中的代码将调用返回例程。但是memcpy@GLIBC_2.2.5的返回值是目标参数而不是函数地址，所以你应该立即崩溃。）

如果有人能给我一些见解

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

与第三方供应商合作，以获得与您的执行环境兼容的库版本，或
使您的执行环境与您提供的库兼容（即更新您的操作系统）。您可能应该无论如何，因此您的系统无法通过最近的漏洞（例如CVE-2015-7547）做好准备。

<强>更新

我没有使用memcpy返回的值

你并不了解GNU_IFUNC的工作方式。这是一个description。问题是，当你没有使用返回值时，动态链接器会。

动态链接器中的代码类似于：

if (symbol type == STT_GNU_IFUNC) {
  // call the IFUNC to get an address of the actual implementation
  void (*pfun)() = memcpy();
  // call the actual (non-IFUNC) implementation of memcpy.
  return (*pfun)(to, from, size);  // You will crash here!
}

通过asm hack替换非ifunc版本的infunc - 版本，您保证pfun == to，因此您的to被调用就好像它是一个功能。通常应立即SIGSEGV。

memcpy memmove GLIBC_2.14 / 2.2.5的说明

1 个答案: