CVE-2026-112934: filelock: SoftReadWriteLock holder refresh writes through a hard link and hangs on a named pipe that another local user renames over its record

SoftReadWriteLock (and AsyncSoftReadWriteLock, which wraps one) refreshes its holder record (the file under <path>.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 <path>.rw/holders/<token> 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).

A different local user (the other user below) who owns the lock’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’s owner rename or remove it), or because it can write a lock directory without the sticky bit.

A FIFO (a named pipe: a file whose open for writing blocks until some process opens it for reading) makes the lock user’s write_lock() / read_lock() hang regardless of timeout. It also stops a lock holder’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.

Where the kernel lets a user hard-link a file it does not own (a hard link is a second name for the same file; Linux with fs.protected_hardlinks=0; macOS and the BSDs by their defaults, not executed), a hard link makes the lock user overwrite the first ~135 bytes of one of its own private files with its holder record. Affected versions: filelock >= 4.0.0 and <= 4.2.0. Anthropic’s OSS Scanner reported it in private as ANT-2026-AT33VEVC [medium, CWE-62], titled “SoftReadWriteLock holder refresh writes through hard links, hangs on FIFOs”.