The ReadWriteLock and AsyncReadWriteLock components of filelock use SQLite databases for locking, but on Linux, SQLite reopens the lock database by name, following symlinks and acting on side files such as -journal, -wal, and -shm. This behavior allows a local attacker with write permissions in the directory containing the lock database to manipulate these files, causing the lock user to write arbitrary data into their own files, create or unlink files, or cause lock acquisition failures. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with the /proc/self/fd redirect introduced in 4.0.9 and side-file variants since 3.20.4. The CVSS 3.1 score is 7.1 (High), reflecting local attack complexity but high integrity and availability impact. The issue requires a writable, non-sticky directory accessible to the attacker. In sticky directories like /tmp, a planted -wal file causes lock acquisition failures. Kernel settings such as fs.protected_regular and fs.protected_hardlinks influence the exploitability. No confidentiality impact is noted.