[LTP] cve: reproducer for cve-2026-64600
linuxtestproject.agent@gmail.com
linuxtestproject.agent@gmail.com
Fri Jul 24 19:56:24 CEST 2026
Hi Andrea,
On 2026-07-24, Andrea Cervesato wrote:
> cve: reproducer for cve-2026-64600
> +static void cleanup(void)
> +{
> + stop_pressure_threads();
> +
> + if (barrier_initialized)
> + SAFE_PTHREAD_BARRIER_DESTROY(&barrier);
> +
> + if (target_dio_fd != -1)
> + SAFE_CLOSE(target_dio_fd);
> +
> + if (target_fd != -1)
> + SAFE_CLOSE(target_fd);
> +
> + if (clone_fd != -1)
> + SAFE_CLOSE(clone_fd);
> +
> + free(tbuf);
> + free(wbuf);
> + free(rbuf);
> +}
The header comment says "Root privilege is regained in cleanup() so
the library can unmount the loop device", but cleanup() never calls
SAFE_SETEUID(0)/SAFE_SETEGID(0). setup() drops to "nobody" via
drop_privileges() and nothing restores euid/egid afterwards.
Other tests that drop privileges the same way restore them in
cleanup(), e.g. chmod06.c, acct01.c, creat06.c all call
SAFE_SETEUID(0) there. Per capabilities(7), effective capabilities are
cleared once euid moves away from 0, so the process is still
unprivileged when cleanup() returns. The library's subsequent unmount
of the loop device would then fail with EPERM, leaving the mount and
loop device attached.
Is a SAFE_SETEUID(0) (and SAFE_SETEGID(0)) call missing at the start
of cleanup()?
Verdict - Needs revision
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
More information about the ltp
mailing list