CVE-2025-27591

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.