CVE-2026-112907

CVE-2026-112907 · filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break

This page contains facts from public vulnerability sources. Check the original advisory before updating.

This page shows selected source facts. See the linked advisories for the complete description and affected versions.

On Windows the soft locks (`SoftFileLock`, `MarkerSoftFileLock`, `SoftFileLease`, their async forms, and a `FileLock` that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each `acquire()` attempt that finds a marker opens it with `os.open` to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock (opportunistic lock) is a request by a process that holds a handle on a file to be told before another process opens, renames or deletes that file; the other process waits until the holder answers the break or closes its handle. Another local account that can open the marker for reading can take a Level 1 oplock on it while no process holds it open, and leave the break unanswered. Every `acquire()` by the user running the lock (below: the lock user) then waits inside the open, past its `timeout`, `blocking=False` and `cancel_check`, and a stale marker under that oplock is not broken. Mutual exclusion holds and the lock touches no other file. Affected versions are filelock 3.22.0 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the report Anthropic's OSS Scanner sent on 15 October 2026 (review round 4, finding F4); it is not among the scanner's findings. ## Severity **CVSS 3.1 `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L` scores 2.5 (Low).** `AV:L` (local): the other account needs a logon on the same host. `AC:H` (high attack complexity): Windows grants a Level 1 or batch oplock only to the sole open handle on a file, so the marker must have no holder handle when the other account asks. That account cannot bring this about; it waits for a holder that died, closed its descriptor, or left a marker past its `lifetime`. `PR:L` (low privileges): an ordinary account with read access to the marker through the directory's inherited ACL (access control list). `UI:N` (no user interaction). `S:U` (scope unchanged). `C:N` and `I:N`: that account can read the marker's content (process id and host name) anyway, and mutual exclusion holds. `A:L` (partial availability impact): one thread, or the event loop with `run_in_executor=False`, waits until the holder answers; 10 s per attempt in the two-account runs, no crash. Metrics in doubt take the lower reading. Classification from the review: **security, conditional** on an unheld marker that another account can open. ## Scope and preconditions - Platform and classes: Windows only. `SoftFileLock`, `MarkerSoftFileLock`, `SoftFileLease`, `AsyncSoftFileLock` and the other async soft locks, and `FileLock` after its `ENOSYS` fallback to a soft lock. `WindowsFileLock` opens its lock file on a separate code path that this advisory does not cover. - Marker access: the soft locks create the marker with `os.open`, which on Windows applies no more of `mode` than the read-only attribute (GHSA-8mx5-7m5m-r77g). The marker carries the lock directory's inheritable entries. Another account that those entries grant read access to new files can open the marker with a read handle that shares read, write and delete. - Unheld marker: no handle may be open on the marker when the other account requests the oplock. That is a holder that died and left its marker, a holder that closed its descriptor, or a marker whose `lifetime` has passed. While the holder keeps its handle, the request fails. - Holder behavior: the other account requests the oplock through an overlapped `DeviceIoControl` and never acknowledges the break. Windows cancels a thread's pending request when the thread exits, so the holder thread stays alive. A same-account process that answers slowly, such as an indexer, has the same effect for its answer time. - What the lock user sees: `SoftFileLock.acquire(timeout=1)` returned `Timeout` after 10.02 s with the second account's handle. In the same-account probe `os.open` with `O_RDONLY` was still running after 15 s and returned once the holder closed. The retry loop consults `timeout`, `blocking=False` and `cancel_check` between attempts only. With `AsyncSoftFileLock(run_in_executor=False)` the event loop waits. - Stale break: `break_lock_file` renames and unlinks by path. Both calls wait in the same way, so a stale marker under such an oplock stays, and no process acquires the lock until the holder closes. - Not affected: mutual exclusion, and the lock reads, writes and deletes no file other than the marker. ## Affected code Scanned commit `b831496b0273`: the [`os.open` in `_read_lock_file`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L323) ([function](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L312-L335)), called from [`_try_break_stale_lock`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L107-L123) on every attempt that finds a marker, and from [`_unprobeable_holder`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L137), [`pid`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L164) and [`is_lock_held_by_us`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L179). [`break_lock_file`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_util.py#L84-L122) renames at L116 and unlinks at L118 and L122, by path. [`_poll_until_acquired`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_api.py#L1378-L1408) and [`_check_give_up`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_api.py#L1590-L1608) test the deadline, `blocking` and `cancel_check` only between attempts. ## Introduced [e35c3af](https://github.com/tox-dev/filelock/commit/e35c3af) "feat(soft): detect and break stale locks" ([#476](https://github.com/tox-dev/filelock/pull/476), 2026-02-13), first tag 3.22.0 (verified with `git tag --contains`). Before it a soft lock created its marker with `O_CREAT | O_EXCL` and never opened an existing one. #476 read the marker on Windows through `CreateFileW` and broke a stale one with `Path.rename` and `Path.unlink`. These wait for an oplock as `os.open` does, because none of them passes `FILE_COMPLETE_IF_OPLOCKED`, an `NtCreateFile` option that returns instead of waiting. The read became the `os.open` in `_read_lock_file` with [bfbfa76](https://github.com/tox-dev/filelock/commit/bfbfa76) ([#548](https://github.com/tox-dev/filelock/pull/548), 3.29.1) and the break moved into `break_lock_file` with [d244c6d](https://github.com/tox-dev/filelock/commit/d244c6d) ([#551](https://github.com/tox-dev/filelock/pull/551), 3.29.2); the by-path calls stayed. ## Mechanism Each attempt of `_acquire` first calls `os.open(path, O_WRONLY | O_CREAT | O_EXCL)`. On an existing marker that fails with `EEXIST` (or `EACCES` on Windows) at once; the same-account probe shows the failed exclusive create returning at once under an oplock too. `_acquire` then calls `_try_break_stale_lock`, which calls `_read_lock_file`: `os.lstat`, then `os.open(path, O_RDONLY | O_NOFOLLOW | O_NONBLOCK)`. On Windows `O_NOFOLLOW` and `O_NONBLOCK` do not exist (the code reads them with `getattr(os, ..., 0)`), and `os.open` calls `CreateFileW`. When another handle holds a Level 1 or batch oplock on the file, that call sends the holder a break request and returns only when the holder acknowledges it or closes its handle. `_check_give_up` tests the deadline after the attempt returns, so the wait overruns `timeout`, `blocking=False` and `cancel_check` by its length. Once the open returns, the attempt ends and `_check_give_up` raises `Timeout`, because the deadline has passed. A marker whose holder

CVSS 2.5 · Low · Fix available

Published

2026-10-23T22:27:32Z

Updated

2026-10-23T22:45:03.452878321Z

Stack: python

Check your server →