Detections
Analytics

Fedora 44 : btrfs-backup-ng (2026-d5ef07277c)

high Nessus Plugin ID 371732

Synopsis

The remote Fedora host is missing one or more security updates.

Description

The remote Fedora 44 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2026-d5ef07277c advisory.

 Update to 0.9.20. This replaces the 0.9.19 update before it reached testing. It carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, three concurrency and accounting fixes from 0.9.19, and 0.9.20's fix for the shared-lock retry bound, which the previous Fedora build carried as a patch.
 0.9.17 through 0.9.19 were not shipped to this release.

 Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read.
 Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

 Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened;
 stores created by a root timer or over ssh are 0755 and unaffected.
 New stores are created 0755 regardless of umask.

 Also fixed since 0.9.16:
 - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning.
 - A shared snapshot pin no longer fails with could not lock ...
 refusing to continue when another holder releases at the same instant, including under heavy contention on a slow machine.
 - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

 No configuration or on-disk format changes. This update includes all changes since 0.9.16.

 Advisory:
 https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog:
 https://github.com/berrym/btrfs-backup-ng/blob/v0.9.20/CHANGELOG.md

 ----

 Update to 0.9.19. This replaces the 0.9.18 update before it reached testing, so it carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph), the 0.9.18 fix for 0.9.17's btrfs lock regression, and three concurrency and accounting fixes from 0.9.19. 0.9.17 and 0.9.18 were not shipped to this release.

 Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read.
 Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

 Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened;
 stores created by a root timer or over ssh are 0755 and unaffected.
 New stores are created 0755 regardless of umask.

 Also fixed since 0.9.16:
 - A pruned raw stream whose .meta sidecar could not be removed was counted as both deleted and failed; the sidecar is now a warning.
 - A shared snapshot pin no longer fails with could not lock ...
 refusing to continue when another holder releases at the same instant; the acquire retries like the exclusive one does.
 - A released shared pin can no longer be revived by an orphaned keep-alive, and the sweep of abandoned holder records re-checks a record's age at the moment it removes it.

 No configuration or on-disk format changes. This update includes all changes since 0.9.16.

 Carries a patch raising the shared-lock retry bound, sent upstream.

 Advisory:
 https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog:
 https://github.com/berrym/btrfs-backup-ng/blob/v0.9.19/CHANGELOG.md

 ----

 notes=Update to 0.9.18, which carries the 0.9.17 security fix (GHSA-5xvm-66c9-p5ph) and a fix for a regression in 0.9.17. 0.9.17 was not shipped to this release.

 Security: the lock store created directories, wrote holder records and read them back with operations that followed a symbolic link. If the lock-store directory on a backup location was writable by another local account, a planted symlink could redirect those writes and reads; with a backup run as root, as a scheduled backup usually is, that let a less privileged local user steer a root write or read.
 Locally the lock store now works on O_NOFOLLOW file descriptors, and over ssh each directory component is created with a plain mkdir, records are written under set -C, and a record that is a link or not a regular file is refused.

 Breaking: a lock-store directory writable by its group or by everyone is now refused with an error naming the directory and the remedy (chmod go-w <path>). A store created by an earlier version under an interactive umask 002 is mode 0775 and will be refused until tightened;
 stores created by a root timer or over ssh are 0755 and unaffected.
 New stores are created 0755 regardless of umask.

 0.9.18 fixes the 0.9.17 regression where every exclusive lock on a local btrfs destination on kernel 6.6 or newer failed with remote lock ... is busy, so a receive or prune into a local btrfs location could not run.

 This update includes all changes since 0.9.16.

 Advisory:
 https://github.com/berrym/btrfs-backup-ng/security/advisories/GHSA-5xvm-66c9-p5ph Full changelog:
 https://github.com/berrym/btrfs-backup-ng/blob/v0.9.18/CHANGELOG.md

Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Solution

Update the affected btrfs-backup-ng package.

See Also

https://bodhi.fedoraproject.org/updates/FEDORA-2026-d5ef07277c

Plugin Details

Severity: High

ID: 371732

File Name: fedora_2026-d5ef07277c.nasl

Version: 1.1

Type: Local

Agent: unix

Published: 10/24/2026

Updated: 10/24/2026

Supported Sensors: Agentless Assessment, Continuous Assessment, Frictionless Assessment Agent, Nessus Agent, Tenable Cloud Security, Tenable Self-Hosted Container Security, Nessus

Vulnerability Information

CPE: cpe:/o:fedoraproject:fedora:44, p-cpe:/a:fedoraproject:fedora:btrfs-backup-ng

Required KB Items: Host/local_checks_enabled, Host/RedHat/release, Host/RedHat/rpm-list

Exploit Ease: No known exploits are available

Patch Publication Date: 10/23/2026

Vulnerability Publication Date: 10/23/2026

Reference Information