On 2026-03-08 20:32, Ajay S.K wrote:
What happens during the race is the following. At a certain point while mv -f
/tmp/nmap /usr/bin/nmap is executing, my program manages to create /tmp/nmap.
That does not necessarily mean there's a problem.
As I mentioned earlier, the relevant syscalls executed by that mv
command should look like the following:
renameat2(AT_FDCWD, "/tmp/nmap", AT_FDCWD, "/usr/bin/nmap", RENAME_NOREPLACE)
= -1 EEXIST (File exists)
openat(AT_FDCWD, "/usr/bin/nmap", O_RDONLY|O_PATH|O_DIRECTORY) = -1 ENOTDIR
(Not a directory)
newfstatat(AT_FDCWD, "/tmp/nmap", {st_mode=S_IFREG|0755, st_size=138120,
...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/usr/bin/nmap", {st_mode=S_IFREG|0755, st_size=138120,
...}, AT_SYMLINK_NOFOLLOW) = 0
renameat(AT_FDCWD, "/tmp/nmap", AT_FDCWD, "/usr/bin/nmap") = 0
If your attacking program "manages to create" /tmp/nmap while the mv is
executing, that must occur after the last syscall (the renameat) quoted
above. This is because the file /tmp/nmap exists until then, and the
attacker cannot create a file that already exists.
And if your attacking program creates /tmp/nmap after the renameat, the
attacking program can't affect what's in /usr/bin/nmap. All it can do is
create a file /tmp/nmap that nobody else cares about. So privilege
escalation does not occur.
The rest of your email is also incoherent.
We can't debug this from a distance: you'll need to find out what
happened yourself. I suggest starting by using strace on the 'cp'
command, the 'mv' command, and your attacking program, and looking at
the strace output.
