The only reproduction we were able to perform injected via a BMC soft poweroff being triggered.
This then called into kernel/reboot.c (orderly_poweroff where the schedule_work was performed) utilizing the usermodehelper during the run_cmd /sbin/poweroff. On 02/14/2018 09:44 AM, Laurent Bercot wrote: >> When PID=0 in early kernel_init, PID=1 has a skeleton running, this >> detection is not >> >> the Busybox /sbin/init, but a place holder for when the real Busybox >> /sbin/init is do_execve'd > > Are you saying the kernel could spawn a /sbin/reboot process *before* > kernel_init execs into the userspace init? > > If it's the case (and Denys' test will verify it), it's violently out > of spec. There should be no other userspace processes present before > init, and if there are, the behaviour is totally undefined, and things > should very much be expected to fail. It is basically impossible to > program under Unix if you cannot assume there is a pid 1 present that > will reap zombies. > > It would be worth it to report the situation to the kernel maintainers > so they make sure the spawning of userspace processes (triggered by > soft-poweroff or anything else) is deferred until after /sbin/init has > been do_execve()'d. > > -- > Laurent > _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
