NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/59837: execve allows argv[0] == NULL



>Number:         59837
>Category:       kern
>Synopsis:       execve allows argv[0] == NULL
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 15 05:10:00 +0000 2025
>Originator:     Keith Thompson
>Release:        NetBSD 10.1/amd64
>Organization:
>Environment:
NetBSD qnetbsd 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
I reproduced the problem in a virtual machine running NetBSD 10.1
under Ubuntu 24.04.3.

I've created a GitHub repo with code to demonstrate the problem.

With an unusual invocation of the execve() system call, it's possible
to invoke a program such that argv[0] is a null pointer. This can
create a security hole; see CVE-2021-4034.

I don't think this is non-conforming, but it can create security
problems for programs that don't check for this condition.

References:

https://github.com/Keith-S-Thompson/argv0

https://nvd.nist.gov/vuln/detail/cve-2021-4034

>How-To-Repeat:
Clone my git repo, run "make", then run "./caller"

-- OR --

caller.c:
```
#include <unistd.h>
int main(void) {
    extern char **environ;
    char *arg0 = NULL;
    execve("./callee", &arg0, environ);
}
```

callee.c:
```
#include <stdio.h>
int main(int argc, char **argv) {
    printf("argc = %d\n", argc);
    for (int i = 0; i <= argc; i ++) {
        printf("argv[%d] = ", i);
        if (argv[i] == NULL) {
            puts("NULL");
        }
        else {
            printf("\"%s\"\n", argv[i]);
        }
    }
}
```

Compile both source files and run "./caller". The output is:
```
argc = 0
argv[0] = NULL
```

The output on a Linux system that has a fix for this problem is:
```
argc = 1
argv[0] = ""
argv[1] = NULL
```
>Fix:
Unknown, but my git repo cites a fix for the corresponding issue
in the Linux kernel. FreeBSD 14.2 apparently also has a fix for it.



Home | Main Index | Thread Index | Old Index