filelock vulnerabilities

In filelock from 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user.

In filelock from 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name. On POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations; a writable adjacent hot journal is additionally required for attacker-chosen content overwrites.

In filelock from 3.22.0 until 4.2.1, SoftFileLock trusted a forged process identifier in a marker that an attacker could modify but not remove. This allowed an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder.

In filelock from 4.1.0 until 4.2.1, ReadWriteLock could remove a randomized .filelock-* private-hard-link directory during cleanup. Another local user with rename access in a non-sticky parent could observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion.

In filelock from 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock resolved the lock path and passed it to SQLite without rejecting a final symbolic link. Another local user who can create names in the lock directory could redirect database creation and locking or split mutual exclusion between targets.

In filelock from 3.22.0 until 4.2.1, SoftFileLock could break a stale marker after an attacker freed its own marker following the stale read, an honest contender created a live successor on the reused inode, and the successor's modification time was not newer than the saved observation, causing the live marker to be removed and two holders to be admitted.

In filelock from 4.0.0 until 4.2.1, SoftReadWriteLock refreshed holder records by name. Another local user with rename access to the lock directory could replace a record with a named pipe and stall the lock, or under a permissive hard-link policy link a reachable target file and cause the lock user to write through it.

In filelock from 3.20.4 until 4.2.1, ReadWriteLock could open a crafted SQLite lock database without bounding schema and query work. Another local user who can replace the database could make acquisition stall or hang.

In filelock from 4.1.0 until 4.2.1, SoftFileLock could restore a stale marker by name after moving it aside. Another local user with rename access in a non-sticky lock directory could swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory.

In filelock from 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result.

In filelock from 3.30.0 until 4.2.1, StrictSoftFileLock (from 3.30.0) and SoftReadWriteLock (from 4.0.0) could adopt a protocol directory created first by another local user in a shared parent directory. This allowed that user to alter protocol state and admit concurrent holders.

filelock before 4.2.1 has a vulnerability in UnixFileLock that can truncate a regular file renamed onto the lock path when another local user has rename permission or hard-linked there under a permissive policy. When an explicit mode is requested, versions from 3.10.2 can also change that file's mode.

filelock from 4.1.0 to 4.2.1 has a vulnerability in SoftFileLock that can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, and coarse or matching modification times preserve the observation. This can cause a live marker to be removed as stale.