src/filelock/_unix.py | 2 1 + 1 - 0 !
src/filelock/_windows.py | 38 38 + 0 - 0 !
2 files changed, 39 insertions(+), 1 deletion(-)

 [patch] fix toctou symlink vulnerability in lock file creation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A race condition existed between checking if the lock file exists and opening it with O_TRUNC, allowing
local attackers to create a symlink pointing to victim files. When the lock was acquired, os.open() would
follow the symlink and truncate the target file, causing data loss or corruption.

The vulnerability affected both Unix and Windows platforms and cascaded through dependent libraries:
- virtualenv: Could overwrite user configs with virtualenv metadata, leaking file contents
- PyTorch: Could truncate CPU ISA cache causing crashes, or corrupt compiled model checkpoints preventing
  model loading (DoS for ML pipelines)

Unix/Linux/macOS fix:
- Add O_NOFOLLOW flag to os.open() call in UnixFileLock._acquire()
- System returns ELOOP error if lock path is a symlink, preventing the attack

Windows fix:
- Use GetFileAttributesW API via ctypes to detect reparse points (symlinks/junctions)
- Refuse to open lock file if FILE_ATTRIBUTE_REPARSE_POINT flag is set
- Raises OSError before attempting to open, closing the race window

This addresses CWE-362 (Race Condition), CWE-367 (TOCTOU), and CWE-59 (Link Following).

Reported-by: @tsigouris007
Signed-off-by: Bernt Gbor <bgabor8@bloomberg.net>