AI Anthropic wykryła jedną lukę w Linuksie, przeoczyła drugą tuż obok niej

Model sztucznej inteligencji Mythos od Anthropic przeanalizował około 2500 linii kodu podsystemu epoll w jądrze Linuksa i wykrył w nim poważną lukę bezpieczeństwa, oznaczoną jako CVE-2026-43074. Kilka linii dalej, w tym samym fragmencie kodu, przeoczył jednak drugą, równie groźną wadę. Odkrył ją dopiero badacz Jaeyoung Chung, który przekształcił ją w działający exploit skuteczny w niemal każdej próbie.

Jak działa luka Bad Epoll

Epoll to mechanizm jądra Linuksa, z którego korzysta niemal każda nowoczesna usługa systemowa, przeglądarka internetowa i aplikacja na Androidzie do jednoczesnego monitorowania wielu plików i połączeń sieciowych. Błąd wprowadzony zmianą w kodzie z 2023 roku polega na wyścigu dwóch ścieżek jądra, które jednocześnie sprzątają ten sam obiekt wewnętrzny: jedna zwalnia pamięć, druga w tym samym momencie wciąż do niej zapisuje.

Skutkiem jest klasyczny błąd use-after-free, który pozwala dowolnemu lokalnemu użytkownikowi bez uprawnień administratora podnieść je do poziomu roota. Atak wymaga trafienia w okno czasowe szerokości zaledwie sześciu instrukcji procesora, co teoretycznie powinno czynić exploitację trudną. W praktyce badacz Jaeyoung Chung opracował proof-of-concept, który działa niezawodnie w około 99 procentach uruchomień na testowanych systemach.

Dlaczego AI przeoczyła błąd tuż obok

Najbardziej uderzającym elementem sprawy jest to, że Mythos, model Anthropic wykorzystywany do automatycznego audytowania kodu jądra, zbadał dokładnie ten sam fragment epoll i znalazł w nim inny, spokrewniony błąd wyścigu (CVE-2026-43074), zanim ktokolwiek zauważył Bad Epoll. Model najwyraźniej przyjrzał się temu obszarowi kodu z realną dokładnością, skoro wychwycił błąd tego samego typu, a mimo to nie zauważył sąsiedniej luki.

Analitycy bezpieczeństwa wskazują dwa prawdopodobne powody. Po pierwsze, okno wyścigu w Bad Epoll jest ekstremalnie wąskie, około sześciu instrukcji, co utrudnia modelowi wyobrażenie sobie dokładnego przeplotu wątków nawet przy analizie samego kodu źródłowego. Po drugie, po załataniu pierwszej luki błąd use-after-free w Bad Epoll zwykle nie uruchamia KASAN, głównego mechanizmu jądra do wykrywania błędów pamięci w czasie działania, więc brakowało dowodów behawioralnych, które mogłyby naprowadzić model.

Zespół wdrożył od tego czasu silniejsze zabezpieczenia i od dawna planowaliśmy to wycofać - Thariq Shihipar, Anthropic

Co to znaczy dla audytu kodu przez AI

Sprawa Bad Epoll nie podważa sensu używania modeli AI do wyszukiwania luk bezpieczeństwa, bo Mythos rzeczywiście znalazł błąd wyścigu, zadanie notorycznie trudne nawet dla doświadczonych audytorów-ludzi. Pokazuje za to, że obecne modele mają ślepe punkty przy analizie skrajnie wąskich okien czasowych i błędów, które nie zostawiają śladów w standardowych narzędziach detekcyjnych jak KASAN. To istotna wskazówka dla firm, które zaczynają polegać na automatycznym audycie AI jako substytucie, a nie uzupełnieniu przeglądu przez ludzi.

Na razie nie ma dowodów, by luka była wykorzystywana w rzeczywistych atakach, nie widnieje na liście znanych wykorzystywanych luk CISA, a jedyny działający kod to publiczny proof-of-concept z programu kernelCTF. Łatki są już dostępne w commicie a6dc643c6931, a administratorzy systemów Linux i Android są proszeni o możliwie szybką aktualizację, zwłaszcza że błąd można teoretycznie połączyć z osobną luką w przeglądarce, by wyjść z piaskownicy Chrome.

Dla polskich zespołów bezpieczeństwa i administratorów systemów Linux płynie z tego prosty wniosek: łatanie epoll powinno mieć wysoki priorytet, niezależnie od tego, że jedna z dwóch powiązanych luk została wykryta przez AI, a druga nie. Historia pokazuje też, że raporty modeli takich jak Mythos warto traktować jako jeden z elementów audytu, nie jako gwarancję kompletności przeglądu bezpieczeństwa krytycznego kodu jądra.

Źródła: The Hacker News (thehackernews.com), Tech Times (techtimes.com), Notebookcheck Polska (notebookcheck.pl), Security Affairs (securityaffairs.com)