CVE-2022-42917 in FRRouting
Summary
by MITRE • 09/14/2026
In FRRouting FRR before 8.5, the service user (usually frr) can escalate its privileges to root by monitoring the configuration directory (/etc/frr) and replacing config files upon creation with, for example, symlinks to change the ownership of arbitrary files. This is a TOCTOU Race Condition caused by a combination of touch and chown.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in FRRouting versions prior to 8.5 represents a critical privilege escalation flaw rooted in improper handling of file system operations within the configuration management subsystem. The core issue stems from a Time-of-Check-to-Time-of-Use race condition, commonly referred to as TOCTOU, which occurs during the initialization and reloading processes where the FRR daemon interacts with its configuration directory located at /etc/frr. Under normal operational circumstances, the service runs under an unprivileged user account, typically named frr, to adhere to the principle of least privilege. However, due to a flawed sequence involving touch and chown system calls, this boundary can be bypassed by a local attacker possessing access to the same configuration directory or sufficient permissions to create files within it.
The technical mechanism behind this exploitation relies on the atomicity gap between checking file existence and modifying its attributes. When FRR attempts to process configuration changes, it may perform operations that involve creating new temporary files or updating existing ones before applying ownership settings. An attacker can exploit this window by monitoring the /etc/frr directory for newly created files using tools like inotifywait. Upon detecting a target file creation event, the attacker rapidly replaces the legitimate file with a symbolic link pointing to an arbitrary sensitive system file, such as /etc/shadow or a binary executable owned by root. Because the subsequent chown operation is applied to the symlink rather than resolving it first, the ownership of the target file pointed to by the symlink is changed to that of the frr user. This effectively grants the unprivileged service account control over critical system resources.
The operational impact of this vulnerability is severe, as it allows for a direct path from an unprivileged local user to root-level access on the affected host. Once the attacker has manipulated file ownership through the symlink attack vector, they can potentially overwrite sensitive configuration files or binaries with malicious content that retains root privileges upon execution by FRR or other system processes triggered during normal operation. This compromises the integrity of the entire routing infrastructure managed by FRRouting and poses a significant risk to network stability and security. In environments where multiple users have access to the server, such as shared hosting or multi-tenant cloud instances, this vulnerability becomes particularly dangerous as it facilitates lateral movement and privilege escalation without requiring external network exposure.
From a classification perspective, this flaw aligns with CWE-367, which defines Time-of-check-Time-of-use (TOCTOU) race conditions in software security. The exploitation technique also maps to MITRE ATT&CK techniques related to Privilege Escalation via File and Directory Permissions Modification, specifically leveraging symbolic links as a vector for bypassing access controls. This highlights the importance of secure coding practices when dealing with file system interactions, particularly regarding atomic operations and proper resolution of symbolic links before applying ownership changes.
Mitigation strategies primarily involve upgrading FRRouting to version 8.5 or later, where these race conditions have been addressed through code hardening that ensures safe handling of configuration files during reloads. In addition to software updates, system administrators should enforce strict file permissions on the /etc/frr directory, ensuring that only authorized processes can write to it. Implementing mandatory access control systems such as SELinux or AppArmor can further restrict the ability of the frr user to create symlinks or modify files outside its designated scope. Regular auditing of configuration directories and monitoring for unexpected file ownership changes are also recommended defensive measures to detect potential exploitation attempts early in their lifecycle.