Tox-dev Filelock: Use of Incorrectly-Resolved Name or Reference (CVE-2026-112909)

UnixFileLock, the backend of FileLock and AsyncFileLock on Unix, empties whatever regular file it finds at the lock path once it holds the flock (a kernel lock on an open file). With an explicit mode it also chmods that file (sets its permission bits), whether or not this acquire created it. Another local user who can rename or hard-link one of the files of the user running the lock (below: the lock user) onto the lock path gets that file truncated by the lock user's next acquire(). A hard link is a second name for the same file. With a mode such as 0o666 the file, still owned by the lock user, also becomes readable and writable by that other user. The other user can then read and alter everything the lock user writes to it afterwards.

O_NOFOLLOW, the defence added for the symlink variant (CVE-2025-68146), does not see a renamed file or a hard link. The rename route needs the file's directory to be writable without the sticky bit (a directory flag that lets only a file's owner remove or rename it). The hard-link route into a sticky directory such as /tmp needs fs.protected_hardlinks=0, a Linux kernel setting. Affected versions are every filelock release up to and including 4.2.0 (the truncation is as old as the project; the chmod since 3.10.2).

Anthropic's OSS Scanner reported this in private. Finding covered by this advisory:

• ANT-2026-KO573NWI [high, CWE-706]: UnixFileLock truncates and chmods victim files renamed onto the lock path.

Severity

CVSS 3.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N scores 6.1 (Medium).

AV:L (local): the other user needs an account on the same host. PR:L (low privileges): an ordinary account is enough. UI:N (no user interaction). AC:L (low attack complexity): one rename or link, then wait for the lock user's next acquire; no race. I:H (high integrity impact): the lock user's own process truncates a file it did not mean to touch, including content behind a second name the other user could neither modify nor delete. With a permissive explicit mode the other user can then write to it. If that file is one the lock user later executes or trusts, that is code execution as the lock user. C:L (partial confidentiality impact): the old content is gone before the other user can read anything, but what the lock user writes afterwards through a descriptor (the number the kernel gives a process for an open file) it still holds is readable. A:N (no availability impact). S:U (scope unchanged).

Classification from the review: security, conditional on another user controlling names in a non-sticky directory on the lock's filesystem (or on fs.protected_hardlinks=0). The scanner rated this high. The maintainers score it medium because the reachable targets depend on the directory layout and kernel settings described below.

Scope and preconditions

• Lock classes: FileLock and AsyncFileLock on Unix (UnixFileLock). SoftFileLock applies an explicit mode only to a file it created with O_CREAT | O_EXCL and does not truncate an existing file. WindowsFileLock has not truncated at any version.
• The other user must put a regular file of the lock user at the lock path before the lock user's next acquire, while the lock file does not exist yet. That is the case on first use, after a reboot, after a /tmp cleaner, or after a release with the default preserve_lock_file=False, which unlinks the file. The scanner checked three ways at the scanned commit, with default kernel settings unless stated:
  • rename inside a directory without the sticky bit (a group-writable project or cache directory, a root-created 0777 directory);
  • rename from such a directory into a sticky one (1777) on the same filesystem. The sticky bit only protects entries that already exist, so the move succeeds while the lock path is free. Once the lock user's lock file exists there, the same move fails with EPERM;
  • link(2) into a sticky directory. This needs a system that lets a user hard-link a file it cannot write, which on Linux means fs.protected_hardlinks=0. Mainstream distributions set 1, which refuses the link. The scanner did not test macOS or the BSDs.
• What the lock user loses: with the default FileLock(path) the lock truncates the file, which keeps its mode. With an explicit mode (a lock shared between users needs 0o666 or 0o660, because UnixFileLock opens the file read-write), the lock also chmods the file to that mode. _apply_explicit_mode suppresses PermissionError only for files the lock user does not own. The lock user owns its own files, so the fchmod succeeds.
• Trust boundary: the protection against another local user holds only when no other user can rename entries in the lock's directory or, for the rename-into-sticky route, in any directory on the same filesystem that holds a file of the lock user. A user who can rename entries in a non-sticky directory above the lock controls every name below it, which no file-based lock can defend against.
• Not affected: a symlink (a file that points at another path) at the lock path, because O_NOFOLLOW makes the open fail with ELOOP; mutual exclusion between cooperating processes.

Affected code

Scanned commit b831496b0273: UnixFileLock._finalize_locked_fd, whose os.ftruncate and _apply_explicit_mode calls have only the st_nlink != 0 guard (the file still has at least one name); _apply_explicit_mode; _open_lock_file, which learns from its O_EXCL create whether this attempt made the file but hands that flag only to the ENOSYS fallback.

Introduced

The truncation of whatever is at the lock path dates from the initial commit (2157efb, which opened with O_TRUNC). The chmod of a pre-existing inode (the kernel's identity for a file, independent of its name) came with d7e1e84 "changed from os.umask to os.chmod" (#206, 2023-03-22), first tag 3.10.2 (verified with git tag --contains). Before it the code passed the mode only to open(), which applies it to a file this call creates. The advisory range is therefore every release up to 4.2.0. The earlier group range >= 3.10.0 understated it, as the review noted.

Mechanism

_open_lock_file first tries os.open(path, O_RDWR | O_NOFOLLOW | O_CREAT | O_EXCL, mode). With the lock user's file renamed to the lock path that fails with FileExistsError. The second os.open(path, O_RDWR | O_NOFOLLOW) succeeds, because the entry is a regular file the lock user owns, and returns created = False. _acquire_native passes created only to the ENOSYS branch. No process holds a flock on the renamed file, so _lock_fd_nonblocking(fd) succeeds at once and _finalize_locked_fd(fd) runs: os.fstat, st_nlink != 0, os.ftruncate(fd, 0), then os.fchmod(fd, mode) when the lock has an explicit mode. Nothing in that path tells a lock file from any other regular file; a link count of 2 and a non-empty file both pass. O_NOFOLLOW does not help because the entry is the file itself (or a hard link, an ordinary directory entry for the same inode), not a symlink to it. There is no race: the other user renames or links once and waits for the next acquire. AsyncUnixFileLock inherits _finalize_locked_fd unchanged.

The scanner measured three variants at the same commit, same accounts (victim