This is a continuation of bug 19861, which reported essentially the same issue for fork instead of vfork. vfork is more difficult to fix because of the tail call requirement (otherwise the return address on the stack in the caller can be clobbered by the vfork subprocess).
Patch: https://sourceware.org/ml/libc-alpha/2019-06/msg00925.html It currently does not work due to bug 24757.
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=41d6f74e6cb6a92ab428c11ee1e408b2a16aa1b0 commit 41d6f74e6cb6a92ab428c11ee1e408b2a16aa1b0 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Jul 2 15:12:20 2019 +0200 nptl: Remove vfork IFUNC-based forwarder from libpthread [BZ #20188] With commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c ("ld.so: Support moving versioned symbols between sonames [BZ #24741]"), the dynamic linker will find the definition of vfork in libc and binds a vfork reference to that symbol, even if the soname in the version reference says that the symbol should be located in libpthread. As a result, the forwarder (whether it's IFUNC-based or a duplicate of the libc implementation) is no longer necessary. On older architectures, a placeholder symbol is required, to make sure that the GLIBC_2.1.2 symbol version does not go away, or is turned in to a weak symbol definition by the link editor. (The symbol version needs to preserved so that the symbol coverage check in elf/dl-version.c does not fail for old binaries.) mips32 is an outlier: It defined __vfork@@GLIBC_2.2, but the baseline is GLIBC_2.0. Since there are other @@GLIBC_2.2 symbols, the placeholder symbol is not needed there.
Fixed in 2.30.