linux-kernel - Re: vfork(2) behavior not consistent with fork(2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k0c2qagv.fsf@oldenburg.str.redhat.com>
Date:   Wed, 06 Apr 2022 21:26:56 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Alejandro Colomar <alx.manpages@...il.com>
Cc:     Christian Brauner <brauner@...nel.org>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        linux-kernel@...r.kernel.org,
        Коренберг Марк 
        <socketpair@...il.com>, Andrei Vagin <avagin@...nvz.org>,
        Dmitry Safonov <dima@...sta.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>, Serge Hallyn <serge@...lyn.com>,
        bugzilla-daemon@...nel.org, linux-api@...r.kernel.org
Subject: Re: vfork(2) behavior not consistent with fork(2)

* 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