RUSTSEC-2025-0149: World Writable Directory in /var/log/below Allows Local Privilege Escalation

What to do

1. See which version you have: cargo tree -i below (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p below. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example below = "0.9.0") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Below is a tool for recording and displaying system data like hardware utilization and cgroup information on Linux.

Symlink Attack in /var/log/below/error_root.log

Below's systemd service runs with full root privileges. It attempts to create a world-writable directory in /var/log/below. Even if the directory already exists, the Rust code ensures 1 that it receives mode 0777 permissions:

    if perm.mode() & 0o777 != 0o777 {
        perm.set_mode(0o777);
        match dir.set_permissions(perm) {
            Ok(()) => {}
            Err(e) => {
                bail!(
                    "Failed to set permissions on {}: {}",
                    path.to_string_lossy(),
                    e
                );
            }
        }
    }

This logic leads to different outcomes depending on the packaging on Linux distributions:

• in openSUSE Tumbleweed the directory was packaged with 01755 permissions (below.spec 2 line 73), thus causing the set_permissions() call to run, resulting in a directory with mode 0777 during runtime.
• in Gentoo Linux the directory is created with mode 01755 resulting in the same outcome as on openSUSE Tumbleweed (below.ebuild 3). Where the 01755 mode is exactly coming from is not fully clear, maybe the cargo build process assigns these permissions during installation.
• in Fedora Linux the directory is packaged with 01777 permissions, thus the set_permissions() code will not run, because the if condition masks out the sticky bit. The directory stays at mode 01777 (rust-below.spec 4).
• the Arch Linux AUR package 5 (maybe wrongly) does not pre-create the log directory. Thus the set_permissions() code will run and create the directory with mode 0777.

Below creates a log file in /var/log/below/error_root.log and assigns mode 0666 to it. This (somewhat confusingly) happens via a log_dir variable 6, which has been changed to point to the error_root.log file. The 0666 permission assignment to the logfile happens in logging::setup() 7, also accompanied by a somewhat strange comment in the code.

A local unprivileged attacker can stage a symlink attack in this location and cause an arbitrary file in the system to obtain 0666 permissions, likely leading to a full local root exploit, if done right, e.g. by pointing the symlink to /etc/shadow. Even if the file already exists it can be removed and replaced by a symlink, because of the world-writable directory permissions. The attack is thus not limited to scenarios in which the file has not yet been created by Below.

Further Issues

Even on Fedora Linux, where /var/log/below has "safe" 01777 permissions, there is a time window during which problems can arise. As long as below.service has not been started, another local user can pre-create /var/log/below/error_root.log and e.g. place a FIFO special file there. This will pose a local DoS against the below service, since it will fail to open the path and thus fail to start.

If /var/log/below were to be deleted for any reason, then Below would still recreate it using the bad 0777 mode permissions, which can also happen on distributions that initially package /var/log/below using permissions that do not trigger the set_permissions() call in Below's code.

References

• Package: crates.io/crates/below
• Advisory: rustsec.org/advisories/RUSTSEC-2025-0149.html
• Web: www.openwall.com/lists/oss-security/2025/03/12/1

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.