bug#80572: [BUG] Privilege escalation via cp trying to replace file contents using root privileges

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.