Cytat z changeloga

Zabezpieczenie przed sytuacjami wyścigowymi w fcntl_setlk()/close() ma subtelną dziurę - musimy się upewnić, że gdy dojdzie do wyścigu fcntl/close na maszynie SMP, kolejność dostępu do tablicy deskryptorów i inode->i_flock nie zostanie zmieniona.

Jeśli się tak stanie, dostajemy STORE inode->i_flock, LOAD descriptor table entry przeciw STORE descriptor table entry, LOAD inode->i_flock bez ani jednej blokady po żadnej ze stron. Mamy BKL (Big Kernel Lock) wokół pierwszego STORE, jednak sprawdzanie w locks_remove_posix() jest poza BKL a są dobre powody dla których nie chcemy BKL w ogólnej ścieżce close(2).

Rozwiązaniem jest zablokowanie ->file_lock wokół fcheck()…

Wprawdzie nie został jeszcze udostępniony żaden exploit wykorzystujący tę lukę, jednak zaleca się przeprowadzenie szybkiej aktualizacji systemu do wersji 2.6.25.2 lub 2.6.24.7.

Błąd zostanie opisany jako CVE-2008-1669 na ulubionej stronie script kiddies.

Update:

Willy Tarreau powiadomił o wydaniu wersji 2.4.36.4 również poprawiającej ten błąd.

Więcej informacji: http://git.kernel.org/?p=linux/kernel/gi...e760fca2e9