We use these services and cookies to improve your user experience. You may opt out if you wish, however, this may limit some features on this site.
Please see our statement on Data Privacy.
In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
Reserved 2025-02-26 | Published 2025-02-26 | Updated 2025-02-26 | Assigner Linuxgit.kernel.org/...c/41f6ea5b9aaa28b740d47ffe995a5013211fdbb0
git.kernel.org/...c/98e0c7c702894987732776736c99b85ade6fba45
git.kernel.org/...c/b50fb8dbc8b81aaa126387de428f4c42a7c72a73
git.kernel.org/...c/1fe82bfd9e4ce93399d815ca458b58505191c3e8
git.kernel.org/...c/27a6f495b63a1804cc71be45911065db7757a98c
git.kernel.org/...c/1290eb4412aa0f0e9f3434b406dc8e255da85f9e
git.kernel.org/...c/a8054d3fa5deb84b215d6be1b910a978f3cb840d
git.kernel.org/...c/cfbfff8ce5e3d674947581f1eb9af0a1b1807950
git.kernel.org/...c/dcd46d897adb70d63e025f175a00a89797d31a43
Support options