Na początku lipca opisywaliśmy Bad Epoll i postawiliśmy tezę, która wydawała się dobrze udokumentowana. Dwa bliźniacze błędy pochodziły z tej samej zmiany w kodzie jądra z 2023 roku. Model Mythos, przeczesując ten fragment, znalazł jeden z nich i przeoczył drugi — a ten drugi wykrył człowiek. Wyjaśnienie było konkretne: okno wyścigu miało szerokość około sześciu instrukcji maszynowych, a uszkodzenie pamięci nie wyzwalało KASAN, głównego detektora błędów pamięci w jądrze. Nie było sygnału, na którym automat mógłby się zaczepić. Wniosek brzmiał: AI jest znakomita w tym, co zapisane wprost w kodzie, i ślepa na to, co istnieje wyłącznie w splocie zdarzeń w czasie.
28 lipca STAR Labs opublikował exploit na kolejny wyścig w jądrze Linuksa — i przy okazji rozbił ten wniosek w miejscu, w którym wydawał się najmocniejszy.
CVE-2026-53264 to błąd typu use-after-free w podsystemie kontroli ruchu sieciowego, pozwalający zwykłemu użytkownikowi zostać rootem. Badacz Lee Jia Jie podaje, że sztuczna inteligencja pomogła mu w trzech miejscach: przy samym znalezieniu błędu, przy wytworzeniu dowodu koncepcji dla KASAN oraz przy optymalizacji okna wyścigu. Czyli dokładnie tam, gdzie trzy tygodnie wcześniej narysowaliśmy granicę.
Nie zamierzam udawać, że tego nie napisaliśmy. Ale nie zamierzam też odwoływać tezy, bo po przyjrzeniu się szczegółom okazuje się, że granica istnieje — tylko przebiega gdzie indziej, niż ją postawiliśmy.
Co dokładnie znaleziono
Błąd siedzi w funkcji tcf_idr_check_alloc(), która wyszukuje współdzielone akcje kontroli ruchu po indeksie. Mechanizm jest podręcznikowym przykładem niedopasowania blokad. Jądro wykonuje wyszukiwanie akcji pod rcu_read_lock() — lekką blokadą odczytu, która zakłada, że obiekty nie znikną w trakcie. Tymczasem obiekty akcji mogą zostać zwolnione pod innymi blokadami, bez odczekania okresu karencji RCU, który gwarantowałby, że żaden czytelnik ich już nie trzyma. Powstaje okno, w którym zwolniony obiekt zostaje odzyskany przez inną alokację, zanim sprawdzi się jego licznik referencji — a stamtąd już prosta droga do kontrolowanego uszkodzenia pamięci.
Skutek w praktyce: lokalna eskalacja uprawnień do roota, zademonstrowana na CentOS Stream 9, z pełnym kodem exploita opublikowanym publicznie. Warto od razu zaznaczyć, co ogranicza realne ryzyko. To nie jest zdalne wykonanie kodu — atakujący musi już mieć przyczółek na maszynie. Demonstrowany exploit wymaga włączonych nieuprzywilejowanych przestrzeni nazw, dwóch konkretnych opcji konfiguracyjnych jądra oraz łańcucha ROP z przesunięciami zaszytymi pod konkretną wersję jądra. Poprawka trafiła do jądra 1 czerwca i została przeniesiona do kilku stabilnych gałęzi. W katalogu znanych eksploatowanych podatności luki nie ma i na 28 lipca nikt nie potwierdził ataków w realnym ruchu.
Przy okazji tych samych badań powstały kolejne znaleziska, w tym CVE-2026-64300 w podsystemie zdarzeń wydajnościowych. To nie był więc jeden strzał, tylko seria — co samo w sobie coś mówi o tempie.
Szczegół, który odwraca naszą własną argumentację
Przy Bad Epoll wskazaliśmy dwa powody, dla których automat przeoczył błąd. Pierwszy: okno sześciu instrukcji, którego nie widać, czytając kod linijka po linijce. Drugi, ważniejszy: uszkodzenie pamięci nie wyzwalało KASAN, więc nie było sygnału w czasie działania, na który mógłby zareagować skaner.
A teraz zestawmy to z tym, w czym AI pomogła Lee Jia Jie. Jednym z trzech etapów było wytworzenie dowodu koncepcji dla KASAN.
To jest odwrócenie, które warto zobaczyć wyraźnie. W Bad Epoll brak sygnału KASAN był powodem, dla którego maszyna nic nie zauważyła. Tutaj sygnał KASAN nie istniał sam z siebie — został skonstruowany, i AI brała w tym udział. Różnica nie polega na tym, że model nagle zaczął widzieć czas. Polega na tym, że gdy człowiek wie, gdzie patrzeć i każe zbudować oprzyrządowanie, które ten konkretny błąd ujawni, brakujący sygnał przestaje być barierą. Można go wyprodukować.
To samo dotyczy trzeciego etapu — zawężania okna wyścigu. Optymalizacja okna nie jest zadaniem wymagającym intuicji o czasie. Jest zadaniem iteracyjnym: zmień parametr, uruchom, zmierz, powtórz kilkaset razy. To jest praca, w której szybkość iteracji przekłada się bezpośrednio na wynik — i dokładnie ten rodzaj pracy, w którym asysta maszynowa daje największy przyrost.
Gdzie naprawdę biegnie granica
Zestawmy oba przypadki, bo dopiero razem układają się w sensowną regułę.
W Bad Epoll model działał w trybie przeczesywania. Dostał fragment kodu i miał znaleźć w nim błędy — bez podpowiedzi, gdzie szukać, bez hipotezy do przetestowania, bez oprzyrządowania zbudowanego pod konkretny scenariusz. W tym trybie znalazł jeden błąd i minął drugi, bo drugi nie zostawiał śladu, który dałoby się wychwycić z zewnątrz.
W przypadku CVE-2026-53264 model działał w trybie asysty. Człowiek prowadził badanie, przeszedł od analizy znanych błędów do polowania na nieznane, formułował hipotezy, decydował, co instrumentować, i weryfikował, czy wynik ma znaczenie w realnym systemie. AI przyspieszała etapy. Relacje z tych badań mówią wprost, że analiza ręczna pozostała niezbędna — szczególnie przy dopracowywaniu logiki eksploatacji i sprawdzaniu rzeczywistego wpływu.
Granica nie przebiega więc między klasami błędów, jak napisaliśmy. Przebiega między trybami pracy. Autonomiczne przeczesywanie wciąż ma ślepe pole na to, co nie zostawia sygnału — i Bad Epoll pozostaje ważnym dowodem w tej sprawie. Ale prowadzona asysta tego ślepego pola nie ma, bo to człowiek decyduje, gdzie skierować uwagę, a maszyna dostarcza szybkości tam, gdzie liczy się liczba iteracji.
To rozróżnienie ma praktyczne konsekwencje i dlatego warto było je poprawić. Prognoza wynikająca z naszej pierwotnej tezy brzmiała uspokajająco: pewna klasa błędów zostaje przy ludziach jeszcze przez jakiś czas. Prognoza wynikająca z poprawionej wersji jest inna: każda klasa błędów jest dostępna dla zespołu człowiek plus maszyna, a jedyne, co ogranicza tempo, to liczba ludzi, którzy wiedzą, gdzie patrzeć. A tych ludzi jest znacznie więcej niż systemów zdolnych do autonomicznego polowania.
Uczciwie: czego to ujawnienie nie dowodzi
Trzeba tu zachować dyscyplinę, bo pokusa, żeby zrobić z tego przełom, jest duża, a materiał na to nie pozwala.
Najważniejsze zastrzeżenie sformułowała redakcja The Hacker News, pytając STAR Labs o szczegóły: bez podanego modelu, promptów, nazwy usługi i zapisu interakcji tego ujawnienia nie da się użyć jako miary zdolności AI ani oddzielić wkładu systemu od kierownictwa i osądu badacza. Wiemy, że AI pomogła. Nie wiemy, ile z tego było modelem, a ile człowiekiem, który wiedział, o co pytać. To nie jest zarzut wobec badacza — to normalna sytuacja przy relacji z warsztatu, a nie przy kontrolowanym eksperymencie. Ale oznacza, że każdy, kto zrobi z tego benchmark, nadinterpretuje.
Sam Lee Jia Jie zastrzega przy tym, że AI wciąż ma luki w rozumowaniu i ślepe pola. To jest ostrożność autora, którą warto powtórzyć, bo jest zgodna z tym, co widzieliśmy w innych miejscach — choćby przy badaniu kodu generowanego przez AI, gdzie modele opanowały wzorce lokalne i zawodziły przy błędach wymagających rozumowania o całej aplikacji.
I rzecz ostatnia, o zakresie: to jest lokalna eskalacja uprawnień z wąskimi warunkami, nie zdalne przejęcie. Poprawka istnieje od czerwca. Publikacja pełnego kodu exploita podnosi ryzyko dla niezałatanych systemów, ale nie tworzy sytuacji kryzysowej.
Co z tego wynika dla obrońcy
Rzecz pierwsza jest zwyczajna: zaktualizuj jądro, biorąc wersję od swojej dystrybucji, a nie kierując się samym numerem wersji z drzewa głównego, bo poprawki są przenoszone do gałęzi stabilnych osobno. Jeśli twoje systemy mają włączone nieuprzywilejowane przestrzenie nazw i nie potrzebujesz ich, warto rozważyć ich wyłączenie — to ogranicza całą rodzinę tego typu ataków, nie tylko ten jeden.
Rzecz druga jest planistyczna i wynika z trybu, w jakim to badanie powstało. Skoro asysta maszynowa najbardziej przyspiesza etapy iteracyjne — budowanie oprzyrządowania, zawężanie okna, dopracowywanie warunków — to należy oczekiwać, że skróci się nie czas znajdowania pierwszej luki, lecz czas przekształcania znaleziska w działający exploit. To jest inne przesunięcie niż to, o którym pisaliśmy przy Squidzie i Rediksie, gdzie chodziło o wykrywanie starych błędów. Tu chodzi o drogę od zgłoszenia do broni. Kto planuje okna serwisowe, powinien zakładać, że ta droga skraca się szybciej niż sama droga od kodu do zgłoszenia.
Rzecz trzecia dotyczy tego, jak czytamy takie doniesienia. W najbliższych miesiącach będzie ich więcej i większość będzie miała tę samą strukturę: badacz mówi, że AI pomogła, bez podania szczegółów. Właściwe pytanie nie brzmi „czy AI to zrobiła", bo odpowiedź prawie zawsze będzie brzmiała „częściowo". Brzmi: czy działała samodzielnie, czy była prowadzona — bo to rozróżnienie decyduje o tym, ile takich zespołów może działać równolegle i jak szybko rośnie tempo.
Jedna myśl na koniec
Trzy tygodnie temu napisaliśmy, że wiedza o tym, gdzie maszyna nie patrzy, jest dziś warta tyle samo co wiedza, co maszyna potrafi znaleźć. Podtrzymuję to zdanie — z jedną poprawką, którą wymusił ten przypadek. Ślepe pole nie jest cechą maszyny. Jest cechą maszyny pozostawionej samej sobie. W chwili, gdy staje obok niej ktoś, kto wie, gdzie skierować spojrzenie i jakie oprzyrządowanie zbudować, ślepe pole przestaje istnieć — nie dlatego, że model przejrzał na oczy, lecz dlatego, że dostał od człowieka to, czego mu brakowało: hipotezę i miejsce, w którym warto ją sprawdzić. Bad Epoll pokazał, czego nie widzi automat. Ten przypadek pokazuje, jak niewiele trzeba, żeby przestał być automatem.
Źródła
The Hacker News — omówienie ujawnienia STAR Labs z opisem trzech etapów, w których badacz wskazał udział AI (znalezienie błędu, dowód koncepcji dla KASAN, optymalizacja okna wyścigu), warunkami działania exploita oraz kluczowym zastrzeżeniem, że bez modelu, promptów i zapisu interakcji ujawnienia nie da się użyć jako miary zdolności AI: https://thehackernews.com/2026/07/researcher-says-ai-helped-develop-linux.html
Cyber Press — techniczny opis przyczyny źródłowej: niedopasowania blokad w tcf_idr_check_alloc(), wyszukiwania akcji pod rcu_read_lock() przy zwalnianiu obiektów bez okresu karencji RCU, oraz zastrzeżenie badacza o utrzymujących się lukach w rozumowaniu i ślepych polach AI: https://cyberpress.org/ai-helps-discover-linux-kernel-zero-day/
Cryptika — relacja wskazująca, że badanie przeszło od analizy znanych błędów do polowania na nieznane, że analiza ręczna pozostała niezbędna przy dopracowywaniu logiki eksploatacji, oraz że przy okazji powstały dalsze znaleziska, w tym CVE-2026-64300: https://www.cryptika.com/ai-assisted-research-uncovers-linux-kernel-zero-day-enabling-root-privilege-escalation/
Pełny opis techniczny opublikował sam badacz na swoim blogu (Slippy Blog) wraz z kodem exploita wycelowanego w CentOS Stream 9; STAR Labs udostępnił kod publicznie.
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł