below

Version	Released
`0.9.0` unknown	Feb 26, 2025
`0.8.1` unknown 1 CVE	Apr 05, 2024
`0.7.1` unknown 1 CVE	Jul 31, 2023
`0.7.0` unknown 1 CVE	Jun 23, 2023
`0.6.3` unknown 1 CVE	Oct 28, 2022
`0.6.2` unknown 1 CVE	Oct 06, 2022
`0.5.0` unknown 1 CVE	Jan 28, 2022
`0.4.1` unknown 1 CVE	Nov 11, 2021
`0.4.0` unknown 1 CVE	Oct 21, 2021
`0.3.0` unknown 1 CVE	Jul 19, 2021
`0.2.0` unknown 1 CVE	Jun 15, 2021
`0.1.0` unknown 1 CVE	Nov 07, 2020

0.9.0 unknown

Feb 26, 2025

0.8.1 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Apr 05, 2024

0.7.1 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Jul 31, 2023

0.7.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Jun 23, 2023

0.6.3 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Oct 28, 2022

0.6.2 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Oct 06, 2022

0.5.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Jan 28, 2022

0.4.1 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Nov 11, 2021

0.4.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Oct 21, 2021

0.3.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Jul 19, 2021

0.2.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Jun 15, 2021

0.1.0 unknown

1 CVE

CVE-2025-27591 RUSTSEC-2025-0149 GHSA-9mc5-7qhg-fp3w Mar 12, 2025

World Writable Directory in /var/log/below Allows Local Privilege Escalation

Critical

Local Low Low None

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.

Fixed in


          0.9.0

References

Updated Feb 08, 2026 · Source: OSV.dev

Nov 07, 2020

Activity

Details

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues

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

Further Issues