CVE-2026-112934

W filelock od wersji 4.1.0 do 4.2.1 klasy SoftReadWriteLock i AsyncSoftReadWriteLock buforują pomyślne sprawdzenie drzewa blokad <path>.rw i ponownie rozwiązują jego nazwy podczas późniejszych operacji zapisu, co pozwala innemu lokalnemu użytkownikowi, który może zastąpić to drzewo po pierwszym przejęciu, przekierować zapisy rekordów blokad do katalogów zapisywalnych przez użytkownika blokady.

W filelock od wersji 3.20.4 do 4.2.1 ReadWriteLock pozwala SQLite na ponowne otwieranie bazy danych i plików towarzyszących po nazwie. Na systemach POSIX atakujący z prawem do zmiany nazw w katalogu nadrzędnym bez sticky bit może podmienić te nazwy, powodując nadpisanie lub usunięcie plików; do nadpisania treści wybranej przez atakującego wymagany jest dodatkowo zapisywalny sąsiedni hot journal.

W bibliotece filelock od wersji 3.22.0 do 4.2.1 mechanizm SoftFileLock ufał sfałszowanemu identyfikatorowi procesu w znaczniku, który atakujący mógł modyfikować, ale nie usuwać. Umożliwiało to innemu procesowi tego samego konta lub rootowi działanie jako confused deputy, usunięcie aktywnego znacznika i dopuszczenie kolejnego posiadacza blokady.

W bibliotece filelock od wersji 4.1.0 do 4.2.1 mechanizm ReadWriteLock mógł usuwać losowy prywatny katalog twardych dowiązań .filelock-* podczas czyszczenia. Inny lokalny użytkownik z prawem zmiany nazw w katalogu nadrzędnym bez sticky bit mógł obserwować aktywną nazwę lub sfałszować nazwę sweep i podmienić katalog siostrzany do usunięcia.

W bibliotece filelock od wersji 3.20.4 do 4.0.9 mechanizmy ReadWriteLock i AsyncReadWriteLock rozwiązywały ścieżkę blokady i przekazywały ją do SQLite bez odrzucenia końcowego dowiązania symbolicznego. Inny lokalny użytkownik mogący tworzyć nazwy w katalogu blokady mógł przekierować tworzenie bazy danych lub rozdzielić wzajemne wykluczenie między celami.

W bibliotece filelock od wersji 3.22.0 do 4.2.1 mechanizm SoftFileLock mógł usunąć aktywny znacznik po tym, jak atakujący zwolnił własny znacznik po odczycie stanu nieaktualnego, uczciwy konkurent utworzył następcę na ponownie użytym i-węźle, a czas modyfikacji następcy nie był nowszy niż zapisana obserwacja. Prowadziło to do usunięcia aktywnego znacznika i dopuszczenia dwóch posiadaczy.

W bibliotece filelock od wersji 3.20.4 do 4.2.1 mechanizm ReadWriteLock mógł otworzyć spreparowaną bazę danych blokady SQLite bez ograniczenia pracy schematu i zapytań. Inny lokalny użytkownik mogący zastąpić bazę danych mógł spowodować zawieszenie lub zablokowanie pozyskiwania blokady.

W bibliotece filelock od wersji 4.1.0 do 4.2.1 mechanizm SoftFileLock mógł przywrócić nieaktualny znacznik po nazwie po jego odsunięciu. Inny lokalny użytkownik z prawem zmiany nazw w katalogu blokady bez sticky bit mógł podstawić dowiązanie symboliczne i, w środowisku podążającym za dowiązaniem oraz z celem w tym samym systemie plików, spowodować utworzenie twardego dowiązania do pliku użytkownika blokady.

W filelock od wersji 3.32.6 do 4.2.1 klasa SoftFileLock może podążać za podmienionym dowiązaniem symbolicznym podczas warunkowego sprawdzenia zapisywalności os.access dla węzła bez bitu zapisu właściciela. Pozwala to innemu lokalnemu użytkownikowi na platformie i w konfiguracji katalogu, które podążają za dowiązaniem, wywnioskować na podstawie obserwowalnego wyniku przejęcia, czy wybrana ścieżka istnieje i jest zapisywalna.

W bibliotece filelock od wersji 3.30.0 do 4.2.1 mechanizmy StrictSoftFileLock (od 3.30.0) i SoftReadWriteLock (od 4.0.0) mogły przyjąć katalog protokołu utworzony wcześniej przez innego lokalnego użytkownika we współdzielonym katalogu nadrzędnym. Umożliwiało to temu użytkownikowi zmianę stanu protokołu i dopuszczenie równoczesnych posiadaczy.