of course, it is a vuln, of low severity by example
On Mon, May 4, 2026 at 6:09 AM Jakub Wilk <jwilk () jwilk net> wrote: Collin Funk <collin.funk1 () gmail com>, 2026-05-01 18:49: CVE-2026-35352
We can see that uutils 'mkfifo' creates the fifo with world readable and writable permissions and then uses chmod() which introduces a TOCTOU race that can be exploited by another user creating a symbolic link in it's place:
$ mkfifo --version mkfifo (uutils coreutils) 0.8.0 $ strace mkfifo -m 700 /tmp/fifo [...] umask(000) = 002 umask(002) = 000 mknodat(ATFDCWD, "/tmp/fifo", SIFIFO|0666) = 0 chmod("/tmp/fifo", 0700) = 0 Creating the FIFO with default permission could allow other users to open it before the chmod(..., 0700) call. This is indeed a vulnerability, but unrelated to symlinks, and it's a different issue than the one in the description of CVE-2026-35352: A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the mkfifo utility of uutils coreutils. The utility creates a FIFO and then performs a path-based chmod to set permissions. A local attacker with write access to the parent directory can swap the newly created FIFO for a symbolic link between these two operations. Note that this attack doesn't work in /tmp, because the sticky bit prevents the attacker from deleting or renaming other users' files. The victim would have to do something like "mkfifo /home/mallory/fifo". So, uh, don't do that?
It's questionable if this is a vulnerability at all.
-- Jakub Wilk
On 5/4/26 6:08 AM, Jakub Wilk wrote: Collin Funk <collin.funk1 () gmail com>, 2026-05-01 18:49: CVE-2026-35352
We can see that uutils 'mkfifo' creates the fifo with world readable and writable permissions and then uses chmod() which introduces a TOCTOU race that can be exploited by another user creating a symbolic link in it's place:
$ mkfifo --version mkfifo (uutils coreutils) 0.8.0 $ strace mkfifo -m 700 /tmp/fifo [...] umask(000) = 002 umask(002) = 000 mknodat(ATFDCWD, "/tmp/fifo", SIFIFO|0666) = 0 chmod("/tmp/fifo", 0700) = 0 Creating the FIFO with default permission could allow other users to open it before the chmod(..., 0700) call. This is indeed a vulnerability, but unrelated to symlinks, and it's a different issue than the one in the description of CVE-2026-35352: A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the mkfifo utility of uutils coreutils. The utility creates a FIFO and then performs a path-based chmod to set permissions. A local attacker with write access to the parent directory can swap the newly created FIFO for a symbolic link between these two operations. Note that this attack doesn't work in /tmp, because the sticky bit prevents the attacker from deleting or renaming other users' files. The victim would have to do something like "mkfifo /home/mallory/fifo". So, uh, don't do that?
It's questionable if this is a vulnerability at all. "I don't think it's even a vulnerability if it could be prevented by defense in depth" isn't a great look. :(
But by all means, let's make it a vulnerability anyway (randomly selected): https://www.openwall.com/lists/oss-security/2011/02/23/1
-- Eli Schwartz