From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16939 invoked from network); 2 Aug 2022 18:54:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2022 18:54:03 -0000 Received: (qmail 3656 invoked by uid 550); 2 Aug 2022 18:54:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3622 invoked from network); 2 Aug 2022 18:53:59 -0000 Date: Tue, 2 Aug 2022 14:53:46 -0400 From: Rich Felker To: Tudor Cretu Cc: musl@lists.openwall.com Message-ID: <20220802185346.GS7074@brightrain.aerifal.cx> References: <20220802113036.302819-1-tudor.cretu@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220802113036.302819-1-tudor.cretu@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] clone: Return EINVAL for null stack On Tue, Aug 02, 2022 at 12:30:36PM +0100, Tudor Cretu wrote: > This change aligns the clone wrapper with the man page. If the stack is > null, clone sets errno to EINVAL, instead of throwing a segmentation fault. > --- > src/linux/clone.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/src/linux/clone.c b/src/linux/clone.c > index 8c1af7d3..43a6803b 100644 > --- a/src/linux/clone.c > +++ b/src/linux/clone.c > @@ -1,4 +1,5 @@ > #define _GNU_SOURCE > +#include > #include > #include > #include > @@ -11,6 +12,10 @@ int clone(int (*func)(void *), void *stack, int flags, void *arg, ...) > pid_t *ptid, *ctid; > void *tls; > > + if (!stack) { > + return __syscall_ret(-EINVAL); > + } > + > va_start(ap, arg); > ptid = va_arg(ap, pid_t *); > tls = va_arg(ap, void *); > -- > 2.25.1 This is probably okay, but there's also a bigger discussion to be had here about what to do about clone() -- deciding what the contract is for what usage can be supported, and possibly making the rest produce errors like the above. There's also a matter of the current very-wrong use of va_arg for variadic arguments that might not exist, and which probably *can't* exist in any valid application usage. This came up before as part of the mt-fork work, but was basically deferred indefinitely... Rich