From nobody@FreeBSD.org  Sat Jun  2 05:28:45 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id C26B037B422
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  2 Jun 2001 05:28:41 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f52CSfn65138;
	Sat, 2 Jun 2001 05:28:41 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200106021228.f52CSfn65138@freefall.freebsd.org>
Date: Sat, 2 Jun 2001 05:28:41 -0700 (PDT)
From: jyliu@163.net
To: freebsd-gnats-submit@FreeBSD.org
Subject: execve() doesn't conform to execve(2) spec in syscall manual
X-Send-Pr-Version: www-1.0

>Number:         27835
>Category:       kern
>Synopsis:       [libc] execve() doesn't conform to execve(2) spec in syscall manual
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-standards
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 02 05:30:01 PDT 2001
>Closed-Date:    Tue Dec 07 05:25:23 UTC 2010
>Last-Modified:  Tue Dec 07 05:25:23 UTC 2010
>Originator:     Jiangyi Liu
>Release:        4.3-STABLE
>Organization:
>Environment:
FreeBSD fatcow.home 4.3-STABLE FreeBSD 4.3-STABLE #2: Sat Jun  2 19:59:52 CST 2001     jyliu@fatcow.home:/usr/src/sys/compile/FATCOW  i386

>Description:
According to execve(2), the argument argv is a pointer to a 
null-terminated array of character pointers to null-terminated 
character strings and at least one argument must be presented 
in the array.
But execve("/bin/sh", NULL, NULL) runs without any error. 
Maybe it's harmless, but it doesn't conform to the syscall spec 
and it may tempt people to write non-portable code.
>How-To-Repeat:
Run the following code. Notice it runs without the expected error, EINVAL.
#include <unistd.h>

int main()
{
	if(execve("/bin/sh", NULL, NULL) < 0)
		perror("execve");
}
>Fix:
Following is an attampt to fix this problem. The part of ERRORS
in execve(2) manual need to be updated for a new entry, EINVAL.

---begins here---
--- kern_exec.c.orig    Sat Jun  2 12:32:29 2001
+++ kern_exec.c Sat Jun  2 19:58:48 2001
@@ -548,7 +548,13 @@
                                imgp->argc++;
                        } while ((argp = (caddr_t) (intptr_t) fuword(argv++)));
                }
-       }       
+       }
+
+    /*
+     * at least one argument must be presented in argv
+     */
+    if (!imgp->argc)
+        return (EINVAL);
 
        imgp->endargs = imgp->stringp;
---ends here---

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-standards 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Sat Mar 8 20:48:55 UTC 2008 
Responsible-Changed-Why:  
Assign to freebsd-standards, who may have a view on whether our code 
or documentation should be fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27835 

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, jyliu@163.net
Cc:  
Subject: Re: kern/27835: [libc] execve() doesn't conform to execve(2) spec
	in syscall manual
Date: Fri, 17 Apr 2009 00:26:57 +0200

 POSIX says that passing 0 arguments in execve() is allowed, but an
 application doing it is not strictly POSIX compliant, and that
 applications must handle being started with 0 arguments. The Solaris 10
 man page says something similar.
 
 The test program fails with EFAULT on 7.x, but passing 0 arguments is
 still possible by changing the execve call to
   execve("/bin/sh", (char*[]){ NULL }, NULL)
 That change is good because a null pointer for argv yields undefined
 behaviour (like any function parameter outside the permitted domain).
 
 Another reason not to apply the patch to the kernel is that it uses
 EINVAL which POSIX already defines for a different purpose that seems
 useful to me: to indicate binaries with correct permissions and a valid
 file format that are not supported (e.g. wrong architecture). This
 situation currently results in ENOEXEC. Implementing the POSIX EINVAL
 could improve the 'Syntax error: "(" unexpected' message you get when
 trying to execute an ELF binary for the wrong architecture in sh; some
 other shells and the execlp(3) and execvp(3) libc functions also assume
 an executable is a shell script when they get ENOEXEC.
 
 -- 
 Jilles Tjoelker
State-Changed-From-To: open->closed 
State-Changed-By: das 
State-Changed-When: Tue Dec 7 05:23:24 UTC 2010 
State-Changed-Why:  
The problem noted by the submitter was fixed some time between 4.3-STABLE 
and 7.0-RELEASE. 
The problem noted in Jilles Tjoelker's follow-up is a bug in the application, 
not a bug in the kernel, according to POSIX. (In other words, don't do that!) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27835 
>Unformatted:
