The filelock ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking, but on Linux and POSIX systems, SQLite reopens the lock database by name, following symlinks and acting on side files like -journal, -wal, and -shm. This behavior allows a local attacker with write access to the directory containing the lock database (if it is world- or group-writable without the sticky bit) to manipulate these files, causing the lock user to write arbitrary data into their own files, create or unlink files, or cause lock acquisition failures. The vulnerability affects filelock versions from 3.20.4 through 4.2.0, with the /proc/self/fd redirect introduced in 4.0.9 and side-file variants since 3.20.4. The CVSS 3.1 score is 7.1 (High), reflecting local attack complexity but high integrity and availability impact. A fix is available in version 2.2.0_1.
A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file to forge the process ID (PID) recorded in the marker. This causes another process, running as the lock owner or root, to mistakenly consider the lock stale and remove the live marker, resulting in multiple processes concurrently holding the lock. The issue arises when the marker file is created or modified with group or other write permissions, typically due to an explicit mode or a permissive umask in a sticky or non-removable directory. The vulnerability has a CVSS score of 4.7 (Medium) and impacts integrity but not confidentiality or availability.
A race condition vulnerability exists in filelock's StrictSoftFileLock and AsyncStrictSoftFileLock where a symbolic link swap attack can cause claim files to be created in an attacker-chosen directory. This occurs because the code performs an lstat check on the .filelock directory without following symbolic links, but subsequent operations follow symbolic links in intermediate path components. An unprivileged local user with write access to the shared directory can exploit this to disrupt locking mechanisms, causing denial of service by making locks time out until manually force-broken. The vulnerability affects filelock versions from 3.30.0 up to and including 4.2.0 and has a CVSS score of 5.8 (medium severity). A fix is available in version 2.2.0_1.
The ReadWriteLock and AsyncReadWriteLock classes in the hf product resolve lock file paths following symlinks and pass them to SQLite without refusing symlinks. This allows a local attacker with write access to the lock directory to create or manipulate files the victim process owns at unintended locations, break mutual exclusion between victim processes, or cause SQLite database locking issues. The vulnerability affects versions from 1.6.0 up to but not including 2.2.0 and is fixed in version 2.2.0.
filelock versions 3.22.0 through 4.2.0 contain a vulnerability in the stale-lock break mechanism used by SoftFileLock and related classes. The flaw allows a local user with write access to the lock directory (such as /tmp with sticky bit) to cause two processes of the lock owner to simultaneously hold the same lock by exploiting inode reuse and race conditions. This results in a high integrity impact where concurrent lock holders can write protected data without detection. The issue requires local access and specific filesystem behavior (ext4, xfs, overlayfs).
A vulnerability in the SoftReadWriteLock component of the filelock library (versions >=1.32.0 <2.2.0_1) allows a local user who owns the lock's .rw directory tree to interfere with the lock holder's refresh mechanism. This can cause the lock holder's write or read operations to hang indefinitely when a named pipe (FIFO) is involved, preventing the heartbeat thread from running and leading to multiple processes believing they hold the lock simultaneously. Additionally, on systems where the kernel permits hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock user to overwrite part of one of its own private files with lock holder data. The vulnerability has a CVSS score of 6.1 (medium severity) and affects availability and integrity but not confidentiality.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user with write access to the lock database file path to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking parameters. This is achieved by placing a crafted SQLite database file at the lock path, which causes the SQLite schema loading to stall or spin at high CPU usage. The impact is denial of service (availability) only, with no confidentiality or integrity compromise. Affected versions are filelock 3.20.4 through 4.2.0. A fix is available in version 4.2.1 and later.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user to leak one bit of information about the existence and writability of arbitrary paths. This occurs because the check follows symlinks under certain conditions, revealing whether a path is writable by the lock user. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and requires local access with the ability to create entries in the lock directory. Linux kernel setting fs.protected_symlinks mitigates this in sticky world-writable directories like /tmp, but not in others. The vulnerability has low severity with a CVSS score of 2.5 and no integrity or availability impact.
A vulnerability in filelock's StrictSoftFileLock and SoftReadWriteLock classes allows a local unprivileged user to pre-create the lock protocol directory in shared sticky directories (e.g., /tmp), causing the lock to adopt a directory owned by the attacker. This enables the attacker to interfere with the lock user's claims, potentially allowing multiple writers to enter critical sections simultaneously, corrupting integrity and causing denial of service. The issue affects filelock versions 3.30.0 through 4.2.0 and is fixed in version 2.2.0_1. The vulnerability requires the attacker to win initial ownership of the protocol directory before the lock user's first acquire on that path.
The UnixFileLock component of the FileLock and AsyncFileLock libraries on Unix truncates and may chmod any regular file that another local user renames or hard-links onto the lock path before the lock user's next acquire. This can cause unintended data loss and potentially allow the other user to read and modify the file if a permissive mode is set. The vulnerability affects all filelock releases up to and including 4.2.0, with chmod behavior introduced since 3.10.2. Exploitation requires local access and the ability to rename or hard-link files in certain directory conditions.
The StrictSoftFileLock and AsyncStrictSoftFileLock classes in filelock versions 3.30.0 through 4.2.0 create claim directories with overly permissive permissions due to using bare mkdir() calls. This can allow other local users with write access to these directories to unlink claim files, causing multiple holders to believe they hold the lock simultaneously, leading to integrity issues. The vulnerability requires a specific environment where the umask or default ACL settings leave write permissions for other users on the lock's parent directory. The CVSS score is 5.3 (Medium), reflecting local attack complexity and high integrity impact but no confidentiality loss.