[gaborbernat]

SoftFileLock, MarkerSoftFileLock and SoftFileLease decide whether a lock is free by reading the marker (the file whose presence says a process holds the lock). A contender removes the marker when its record proves the owner gone. Four separate bugs made that proof wrong for a live owner, so a second process acquired beside it and neither got an error. 🐛 The rules are described under stale lock detection. The fix protects a marker from being rewritten by a process of a different account. It cannot protect a marker whose name that account can replace, which a directory without the sticky bit (a directory flag that lets only a file's owner remove it) allows. This resolves GHSA-rfpc-qcw5-3pc4.

A process name forged an NSpid line

When a marker names a dead PID under a bare hostname, the contender looks for the owner in another PID namespace. Since #815 it reads the NSpid line of /proc/<pid>/status for every task with the recorded start token. It read the file in text mode and split it with str.splitlines(). A task chooses its own name, and proc_pid_status(5) prints it raw except for \n and \\. A name such as "\rNSpid:\tx" therefore produced a line of its own, which matched before the real one. int("x") then raised ValueError out of SoftFileLease.acquire(), StrictSoftFileLock.acquire() and lock_path_occupant; a numeric forgery kept a dead owner's marker in place. _innermost_pid now reads bytes and splits only at \n, the one line end the kernel writes.

flowchart LR
    A["Name:\t\rNSpid:\tx"] --> B{split at}
    B -- "str.splitlines()" --> C["forged NSpid line wins"]
    B -- "b'\n' only" --> D["real NSpid line"]
    classDef bad fill:#ffd6d6,stroke:#c1121f,color:#5c0000;
    classDef ok fill:#d8f3dc,stroke:#2d6a4f,color:#1b4332;
    classDef info fill:#cfe4ff,stroke:#1f6feb,color:#0b1f3a;
    class A,B info;
    class C bad;
    class D ok;

Loading

One side could not read the boot id

Since #661 the Linux start token (the value that tells one use of a PID from a later one) folds the boot id into its high 64 bits. It uses 0 when /proc/sys/kernel/random/boot_id cannot be read. systemd's ProcSubset=pid hides /proc/sys from one unit while /proc/<pid>/stat stays readable. That unit and a job beside it then computed different tokens for the same live PID, and owner_is_stale read the mismatch as a recycled PID. A token without a boot id now matches on starttime alone, through _same_start, both for a live PID and in the other-namespace scan. A different starttime, or two different non-zero boot ids, still reads as a recycled PID. A PID reused after a reboot at the same tick now reads as held, which fails closed.

sequenceDiagram
    participant H as holder (boot id hidden)
    participant C as contender (boot id read)
    H->>H: token = 0 << 64 | starttime
    C->>C: token = boot << 64 | starttime
    rect rgb(255, 214, 214)
    Note over C: before: tokens differ, live holder judged recycled
    end
    rect rgb(216, 243, 220)
    Note over C: now: one side lacks the boot id, compare starttime only
    end

Loading

Time namespaces shifted starttime

Since Linux 5.6 the kernel adds the reader's boottime offset to field 22 of /proc/<pid>/stat. time_namespaces(7) describes the offset as the shift a time namespace applies to the boot clock. A holder and a contender in one PID namespace under one hostname, but in time namespaces with different offsets, read two values for one live task. The token comparison from #660 then broke the live holder's marker. process_start_token now returns None when _starttime_unshifted finds a boottime offset in /proc/self/timens_offsets. Such a process records and reads no token and falls back to PID liveness, which fails closed. The offset is read rather than the namespace identity because container runtimes may give every container its own time namespace without an offset; those keep their tokens. The check runs on each read because setns can move a process. A missing /proc/self/ns/time means the kernel has no time namespaces, so tokens are read. Any other failure to read it, such as a denied stat under a restricted /proc, leaves the namespace unknown, so no token is recorded or compared.

flowchart TD
    A[read /proc/self/ns/time] -->|initial namespace or no file| T[token from starttime]
    A -->|unreadable| N
    A -->|other namespace| B{boottime offset 0 and namespace is this process's own?}
    B -->|yes| T
    B -->|no| N[no token: PID liveness only]
    classDef ok fill:#d8f3dc,stroke:#2d6a4f,color:#1b4332;
    classDef info fill:#cfe4ff,stroke:#1f6feb,color:#0b1f3a;
    class A,B info;
    class T,N ok;

Loading

Another account could write the marker

A contender decides from the record inside a soft marker whether its owner is gone. The marker could be created group- or world-writable: an explicit mode such as 0o666 is applied with fchmod since #807, and the default mode follows the umask. A process of a different account that could write the marker but not remove it, for example in a sticky directory, could change the record. A contender of the holder's account then removed the live marker. Contenders only read and rename a marker, so the soft locks now clear the group and other write bits from both the create mode and the explicit mode, as File permissions and mode now states.

sequenceDiagram
    participant H as holder
    participant O as process of another account
    participant C as contender of the holder's account
    H->>H: create marker 0o666
    O->>H: rewrite record to a dead PID
    rect rgb(255, 214, 214)
    C->>C: owner gone, remove marker, acquire beside H
    end
    rect rgb(216, 243, 220)
    Note over H,O: now the marker is 0o644, the rewrite is refused
    end

Loading

A denied lock open on a loaded machine

WindowsFileLock opens its lock file through NtCreateFile, and NTFS answers STATUS_ACCESS_DENIED for a moment while another thread's unlink tears the name down. Since #604 the open retried that status for 0.5 s of wall-clock time and then raised PermissionError. On a loaded machine a process stalled for most of those 0.5 s made only a few probes, so twenty threads contending for one lock raised the error although nothing denied them. The open now makes 250 probes 2 ms apart, so a stall stretches the wait instead of cutting the probes short. A denial that outlasts the probes still raises before the caller's timeout.

sequenceDiagram
    participant A as releasing thread
    participant B as acquiring thread
    A->>A: close, unlink the lock file
    B->>B: NtCreateFile: STATUS_ACCESS_DENIED
    rect rgb(255, 214, 214)
    Note over B: before: 0.5 s pass with 3 probes under load, PermissionError
    end
    rect rgb(216, 243, 220)
    Note over B: now: 250 probes, the name settles, open succeeds
    end

Loading

Behavior changes

SoftFileLock(mode=0o666) now yields a -rw-r--r-- marker. A process in a time namespace with a boottime offset no longer tells a recycled PID from the owner, so a dead owner whose PID was reused keeps its marker until timeout, lifetime or break_lock().