Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     Alejandro Colomar <alx.manpages@gmail.com>
Cc:     Christian Brauner <brauner@kernel.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        linux-kernel@vger.kernel.org,
        =?utf-8?B?0Jo=?= =?utf-8?B?0L7RgNC10L3QsdC10YDQsyDQnNCw0YDQug==?= 
        <socketpair@gmail.com>, Andrei Vagin <avagin@openvz.org>,
        Dmitry Safonov <dima@arista.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Arnd Bergmann <arnd@arndb.de>, Serge Hallyn <serge@hallyn.com>,
        bugzilla-daemon@kernel.org, linux-api@vger.kernel.org
Subject: Re: vfork(2) behavior not consistent with fork(2)
References: <bug-215769-216477@https.bugzilla.kernel.org/>
        <bug-215769-216477-to2O9X1Knw@https.bugzilla.kernel.org/>
        <4fb02f5f-60f9-42af-ddd5-fe5af877231f@gmail.com>
        <20220404080519.pi6izyuop3mmdg2g@wittgenstein>
        <ae2cbf67-aace-bc40-418e-7b41873f814a@gmail.com>
        <20220406084613.3srklyt27qxcmrcx@wittgenstein>
        <f21a06dc-1e2a-87cd-59dc-e8d5245b0a50@gmail.com>
Date:   Wed, 06 Apr 2022 21:26:56 +0200
In-Reply-To: <f21a06dc-1e2a-87cd-59dc-e8d5245b0a50@gmail.com> (Alejandro
        Colomar's message of "Wed, 6 Apr 2022 21:22:13 +0200")
Message-ID: <87k0c2qagv.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Alejandro Colomar:

>> $ sudo ./vfork_newpid
>> vfork_newpid: PID: 8479
>> vfork_newpid: PID 8479 exiting after execve(2): Success
>> print_pid: PID 1 exiting. 
>
>
> I definitely think this is a kernel (or glibc) bug.
> execve(2) is supposed to _never_ return 0 (and errno 0).
> I submitted a new bug to discuss it.
>
> Please see <https://bugzilla.kernel.org/show_bug.cgi?id=215813>

It's not clear if this is valid.  The syscall function in glibc does not
protect the on-stack return address against overwriting, so it can't be
used to call SYS_vfork on x86.

Can you reproduce this with a true inline syscall, or the glibc vfork
function (which protects the return address)?

Thanks,
Florian