Source: python-filelock Version: 4.1.1-1 X-Debbugs-CC: [email protected] Severity: important Tags: security upstream
Hi, The following vulnerabilities were published for python-filelock. CVE-2026-112906[0]: | filelock is a platform-independent file lock for Python. From 4.1.0 | until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale | observation when an attacker pre-dates and removes its own marker, | at least two lock-user processes are waiting, coarse or matching | modification times preserve the observation, and an honest contender | creates a fresh marker on the reused inode, causing that live marker | to be removed as stale. This issue is fixed in version 4.2.1. CVE-2026-112909[1]: | filelock is a platform-independent file lock for Python. Prior to | 4.2.1, UnixFileLock can truncate a regular file renamed onto the | lock path when another local user has actual rename permission, or | hard-linked there under a permissive hard-link policy; when an | explicit mode is requested, affected versions from 3.10.2 can also | change that file's mode. This issue is fixed in version 4.2.1. CVE-2026-112911[2]: | filelock is a platform-independent file lock for Python. From 3.30.0 | until 4.2.1, StrictSoftFileLock versions from 3.30.0 and | SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory | created first by another local user in a shared parent directory, | allowing that user to alter protocol state and admit concurrent | holders. This issue is fixed in version 4.2.1. CVE-2026-112912[3]: | filelock is a platform-independent file lock for Python. 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. This issue is fixed in version 4.2.1. CVE-2026-112914[4]: | filelock is a platform-independent file lock for Python. From 4.1.0 | until 4.2.1, SoftFileLock can restore a stale marker by name after | moving it aside, allowing another local user with rename access in a | non-sticky lock directory to 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. This | issue is fixed in version 4.2.1. CVE-2026-112915[5]: | filelock is a platform-independent file lock for Python. From 3.20.4 | until 4.2.1, ReadWriteLock can open a crafted SQLite lock database | without bounding schema and query work, allowing another local user | who can replace the database to make acquisition stall or hang; | versions from 3.20.4 expose this on initial per-instance opening, | and versions from 3.30.0 repeat the exposure on every acquisition. | This issue is fixed in version 4.2.1. CVE-2026-112934[6]: | filelock is a platform-independent file lock for Python. From 4.0.0 | until 4.2.1, SoftReadWriteLock refreshes holder records by name, | allowing another local user with rename access to the lock directory | to replace a record with a named pipe and stall the lock, or under a | permissive hard-link policy to link a reachable target file and | cause the lock user to write through it. This issue is fixed in | version 4.2.1. CVE-2026-112935[7]: | filelock is a platform-independent file lock for Python. From 3.22.0 | until 4.2.1, SoftFileLock can break a stale marker after an attacker | frees its own marker following the stale read, an honest contender | creates a live successor on the reused inode, and the successor's | modification time is not newer than the saved observation, causing | the live marker to be removed and two holders to be admitted. This | issue is fixed in version 4.2.1. CVE-2026-112937[8]: | filelock is a platform-independent file lock for Python. From 4.1.0 | until 4.2.1, ReadWriteLock can remove a randomized .filelock-* | private-hard-link directory during cleanup, allowing another local | user with rename access in a non-sticky parent to observe a live | name or forge a dead-owner sweep name and rename a sibling directory | onto it for deletion. This issue is fixed in version 4.2.1. CVE-2026-112939[9]: | filelock is a platform-independent file lock for Python. From 3.22.0 | until 4.2.1, SoftFileLock can trust a forged process identifier in a | marker that an attacker can modify but cannot remove, allowing 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. This issue is fixed in version 4.2.1. CVE-2026-112940[10]: | filelock is a platform-independent file lock for Python. 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, while a writable adjacent hot journal is additionally | required for attacker-chosen content overwrites. This issue is fixed | in version 4.2.1. CVE-2026-112941[11]: | filelock is a platform-independent file lock for Python. 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. This | issue is fixed in version 4.2.1. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-112906 https://www.cve.org/CVERecord?id=CVE-2026-112906 [1] https://security-tracker.debian.org/tracker/CVE-2026-112909 https://www.cve.org/CVERecord?id=CVE-2026-112909 [2] https://security-tracker.debian.org/tracker/CVE-2026-112911 https://www.cve.org/CVERecord?id=CVE-2026-112911 [3] https://security-tracker.debian.org/tracker/CVE-2026-112912 https://www.cve.org/CVERecord?id=CVE-2026-112912 [4] https://security-tracker.debian.org/tracker/CVE-2026-112914 https://www.cve.org/CVERecord?id=CVE-2026-112914 [5] https://security-tracker.debian.org/tracker/CVE-2026-112915 https://www.cve.org/CVERecord?id=CVE-2026-112915 [6] https://security-tracker.debian.org/tracker/CVE-2026-112934 https://www.cve.org/CVERecord?id=CVE-2026-112934 [7] https://security-tracker.debian.org/tracker/CVE-2026-112935 https://www.cve.org/CVERecord?id=CVE-2026-112935 [8] https://security-tracker.debian.org/tracker/CVE-2026-112937 https://www.cve.org/CVERecord?id=CVE-2026-112937 [9] https://security-tracker.debian.org/tracker/CVE-2026-112939 https://www.cve.org/CVERecord?id=CVE-2026-112939 [10] https://security-tracker.debian.org/tracker/CVE-2026-112940 https://www.cve.org/CVERecord?id=CVE-2026-112940 [11] https://security-tracker.debian.org/tracker/CVE-2026-112941 https://www.cve.org/CVERecord?id=CVE-2026-112941 Regards, Salvatore
