On Tue, Sep 09, 2025 at 03:50:48PM -0500, tshah wrote:
Hello,
This patch address the issue:
https://lists.busybox.net/pipermail/busybox/2025-September/091718.html. The
patch replaces the use of vfork() with fork() on MMU-enabled targets in the
xvfork() macro.
This change is necessary to resolve a segmentation fault observed on ppc64le
when running: "unshare -mrpf sh".
According to POSIX, there is an udefined behaviour if the child process
created by vfork() either modifies the data other than a variable of type
pid_t or calls any other functions before successfully calling exec (3) or
_exit(2) family functions.
From the strace logs,it looks like the child after vfork performed syscalls
like writing uid_map, gid_map, mounting, etc, which violates the minimal
action requirements of vfork() resulting in a SIGSEGV maybe due to race
conditions.
From my understanding of the problem, vfork() usage, even on non-MMU, is
broken because of the way busybox manipulates globals, affecting the
parent stack.
The fact that it crashes on ppc64le is likely just because of some
architectural differences that make it more likely to happen, but it's
still buggy the way busybox uses it, either way.
The fact the xvfork() is a macro leads me to believe someone (in 2004)
noticed this problem, and using the macro papered over it just enough to
"fix" it.
That being said, it seems everywhere else in busybox uses fork() on MMU
systems, so I guess it makes sense to do the same for xvfork().