filelock: ReadWriteLock follows a symlink at the lock path into SQLite

Summary ReadWriteLock and AsyncReadWriteLock resolve the lock path with pathlib.Path.resolve() and pass it to sqlite3.connect() without refusing a symlink. A local user who can create names in the lock's directory, such as /tmp or a shared cache, can plant a symlink at the lock path and make the victim's process create, lock, or write the file it points to, or break mutual exclusion between the victim's own processes. Details ReadWriteLock.init stores pathlib.Path(lockfile).resolve(), which follows a final symlink, and every connection opens that path through sqlite3.connect() with no ONOFOLLOW or regular-file check. SQLite's own VFS also resolves the final symlink in user space, so fs.protectedsymlinks and the sticky bit do not help: the kernel never sees a symlink to refuse. The other lock classes do not follow a final symlink: FileLock opens with ONOFOLLOW, and SoftReadWriteLock coordinates through .rw/. Proof of concept On Linux, with the victim and attacker as different users and /shared mode 1777 with fs.protectedsymlinks=1: 1. The attacker runs ln -s /home/victim/private/pwned.flag /shared/app.rwlock.db. 2. The victim constructs ReadWriteLock("/shared/app.rwlock.db"). A…

curl https://cve.zerocrew.in/api/cve/CVE-2026-112936