https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 31 Oct 2026 17:58:34 +0000 https://db.gcve.eu/vuln/cve-2026-112934 <p><strong>Affected:</strong> tox-dev filelock</p> <p>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.</p> <p><strong>Affected:</strong> tox-dev filelock</p> <p>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.</p> https://db.gcve.eu/vuln/cve-2026-112934 https://db.gcve.eu/vuln/ghsa-fj95-fr6c-h845 <p><strong>Affected:</strong> PyPI: filelock</p> <p>`SoftReadWriteLock` (and `AsyncSoftReadWriteLock`, which wraps one) refreshes its holder record (the file under `&lt;path&gt;.rw/holders/` that says a process holds or wants the lock) on every poll of a waiting acquire and on every heartbeat (the periodic refresh a holder runs to keep its record fresh). It does so by reopening `&lt;path&gt;.rw/holders/&lt;token&gt;` by name with a plain blocking `O_WRONLY | O_NOFOLLOW` open and writing at offset 0, without checking what it opened. `O_NOFOLLOW` makes the open fail only when the final name is a symbolic link (a file that redirects to another path).</p> <p>A different local user (the other user below) who owns the lock&#39;s `.rw` tree reads the token of the user running the lock (the lock user below) from the `holders/` listing and renames another node over the record. The other user owns the tree because it created it first in a sticky directory such as `/tmp` (the sticky bit is a directory flag that lets only a file&#39;s owner rename or remove it), or because it can write a lock directory without the sticky bit.</p> <p>A FIFO (a named pipe: a file whose open for writing blocks until some process opens it for reading) makes the lock user&#39;s `write_lock()` / `read_lock()` hang regardless of `timeout`. It also stops a lock holder&#39;s heartbeat thread without `on_compromise` (the callback that tells a holder it lost the lock) ever running, so the lock grants a second process while the first still believes it holds it. This works on a default Linux.</p> <p>Where the kernel l…</p> <p><strong>Affected:</strong> PyPI: filelock</p> <p>`SoftReadWriteLock` (and `AsyncSoftReadWriteLock`, which wraps one) refreshes its holder record (the file under `&lt;path&gt;.rw/holders/` that says a process holds or wants the lock) on every poll of a waiting acquire and on every heartbeat (the periodic refresh a holder runs to keep its record fresh). It does so by reopening `&lt;path&gt;.rw/holders/&lt;token&gt;` by name with a plain blocking `O_WRONLY | O_NOFOLLOW` open and writing at offset 0, without checking what it opened. `O_NOFOLLOW` makes the open fail only when the final name is a symbolic link (a file that redirects to another path).</p> <p>A different local user (the other user below) who owns the lock&#39;s `.rw` tree reads the token of the user running the lock (the lock user below) from the `holders/` listing and renames another node over the record. The other user owns the tree because it created it first in a sticky directory such as `/tmp` (the sticky bit is a directory flag that lets only a file&#39;s owner rename or remove it), or because it can write a lock directory without the sticky bit.</p> <p>A FIFO (a named pipe: a file whose open for writing blocks until some process opens it for reading) makes the lock user&#39;s `write_lock()` / `read_lock()` hang regardless of `timeout`. It also stops a lock holder&#39;s heartbeat thread without `on_compromise` (the callback that tells a holder it lost the lock) ever running, so the lock grants a second process while the first still believes it holds it. This works on a default Linux.</p> <p>Where the kernel l…</p> https://db.gcve.eu/vuln/ghsa-fj95-fr6c-h845