Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

A local privilege escalation vulnerability was found in qemu-guest-agent (qga) in the guest-ssh-add-authorized-keys command handler (qga/commands-posix-ssh.c).

When qmp_guest_ssh_add_authorized_keys adds an SSH key for an existing local user, the agent (running as root) checks whether the user's .ssh directory exists using g_file_test with G_FILE_TEST_IS_DIR, which follows symbolic links. It then writes the authorized_keys file via g_file_set_contents (atomic tmp+rename) and changes ownership with a plain chown() — not lchown() or fchown() — so the chown follows symlinks.

A local unprivileged user who controls their home directory can exploit this in two ways:

1. Deterministic directory-symlink bypass (no race): The user creates ~/.ssh as a symlink to a root-owned directory. The IS_DIR test passes (it follows symlinks), mkdir_for_user is skipped, and root writes and chowns a file inside the target directory to the attacker.

2. TOCTOU file-symlink race: Between the atomic rename (g_file_set_contents) and the subsequent chown(), the attacker replaces the authorized_keys path with a symlink to an arbitrary root-owned file. The chown follows the symlink and transfers ownership to the attacker.

In both cases, the attacker gains ownership of arbitrary root-owned files or directories, which can be rewritten to obtain full root access.

The vulnerability requires the host or a management layer (e.g., libvirt virDomainAuthorizedSSHKeysSet, OpenStack Nova, oVirt/RHV) to trigger guest-ssh-add-authorized-keys for the attacker's existing account. The attacker cannot self-trigger the command; it arrives from the host over the QMP/virtio-serial channel.

No privilege drop (seteuid/setuid/setresuid/setfsuid) is performed in the affected code path; all file operations execute with root effective UID.