Re: [PATCH] Replace vfork() with fork() to fix unshare crash on ppc64le

Thanks for the feedback. Yes, agreed, the root issue is the unsafe use 
of vfork() with global variable manipulation before exec(), and not 
specific to ppc64le.

On 10/09/25 01:09, Ben Collins wrote:
> 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().
>