[Bug 7700] busybox init calls vfork() but does not immediately call exec(), probably causing downstream pain

bugzilla at busybox.net bugzilla at busybox.net
Wed Dec 10 11:17:46 UTC 2014


https://bugs.busybox.net/show_bug.cgi?id=7700

--- Comment #1 from Denys Vlasenko <vda.linux at googlemail.com> 2014-12-10 11:17:45 UTC ---
(In reply to comment #0)
> The vfork() man page says that after a vfork(), the child needs to just call
> exec(), and nothing else.  Don't write to stack variables (with the sole
> exception of your pid_t). Don't call any other functions.  Don't even return
> from the current function.  Just call exec(), and if that fails you can call
> _exit().

POSIX rules for vfork are very restrictive because various other Unixes
have restrictive vfork implementations and/or compilers which
do not understand that vfork + needs special treatment.

What init.c is doing after vfork is valid for Linux vfork implementation.

> Don't even return from the current function.

We do obey this, because doing that is almost guaranteed to smash the stack of
the parent.

> Don't call any other functions.

Not even a strlen()? Why?

Please point out which operation in init.c after vfork you consider
questionable.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the busybox-cvs mailing list