AI znalazło jeden błąd w tej samej łatce jądra. Drugi, bliźniaczy, przeoczyło — i po raz pierwszy wiemy dokładnie, gdzie jest jego ślepe pole.

Przez cztery miesiące opisywaliśmy jedną stronę tej historii: AI znajduje błędy, których ludzie nie widzieli latami. Squid czekał dwadzieścia dziewięć lat, Redis dwa, a model Mythos znajdował je w niemal sekundę. Narracja układała się w jedną linię: znajdowanie podatności przestaje być wąskim gardłem, bo maszyna czyta kod szybciej i dokładniej niż człowiek. 3 lipca pojawił się błąd, który dokłada do tej linii coś, czego wcześniej nie mieliśmy — pierwszy konkretny, udokumentowany dowód, gdzie ta maszyna nie patrzy.

Nazywa się Bad Epoll, oznaczony CVE-2026-46242. To luka w jądrze Linuksa, która pozwala zwykłemu użytkownikowi bez żadnych uprawnień przejąć maszynę jako root — na desktopach, serwerach i Androidzie. Jest już załatana. Ale nie dlatego o niej piszemy. Piszemy, bo Bad Epoll pochodzi z tej samej zmiany w kodzie jądra z 2023 roku, w której model Mythos znalazł niedawno inny błąd. AI przeczesało dokładnie ten fragment. Złapało jedną lukę. Drugą, bliźniaczą, siedzącą tuż obok, minęło. Znalazł ją człowiek.

Dwa błędy z jednej łatki

Żeby zobaczyć, dlaczego to jest istotne, trzeba zrozumieć, jak blisko siebie leżały te dwie luki.

W 2023 roku do mechanizmu epoll — standardowej funkcji Linuksa, która pozwala programowi obserwować wiele plików albo połączeń sieciowych naraz — wprowadzono zmianę w kodzie. Epoll jest wszędzie: opierają się na nim serwery, usługi sieciowe, przeglądarki. Nie da się go po prostu wyłączyć. Ta jedna zmiana z 2023 roku zawierała, jak się okazało, dwa osobne błędy. Model Mythos, przeczesując kod jądra w ramach programu znajdowania podatności, wykrył jeden z nich — otrzymał on oznaczenie CVE-2026-43074. To było realne osiągnięcie: błędy tej klasy są notorycznie trudne do wykrycia, a AI je znalazło.

Ale drugi błąd z tej samej łatki pozostał. Wykrył go dopiero badacz Jaeyoung Chung, ręcznie, i zbudował działający atak. To jest Bad Epoll. Dwie luki, jedno źródło, jeden fragment kodu — a mimo to jedna została znaleziona przez maszynę, a druga wymknęła się jej i czekała na człowieka. Pytanie, które to stawia, jest znacznie ciekawsze niż sama luka: dlaczego AI, które przejrzało dokładnie ten kod i znalazło w nim błąd, przeoczyło drugi, leżący tuż obok?

Dlaczego maszyna go minęła

I tu jest sedno całego wpisu — bo po raz pierwszy mamy na to konkretną, techniczną odpowiedź, a nie domysł. Chung podaje dwa powody, i co ważne, sam uczciwie zaznacza, że pełnej pewności nie ma nikt. Ale oba wskazują na tę samą rzecz: na to, jaki typ błędu leży poza zasięgiem obecnego AI.

Po pierwsze — okno czasowe. Bad Epoll jest błędem typu use-after-free, ale nie zwykłym. To wyścig: dwie części jądra próbują posprzątać ten sam wewnętrzny obiekt w tym samym momencie, jedna zwalnia pamięć, gdy druga wciąż w niej pisze. Żeby ten błąd w ogóle zaistniał, dwie operacje muszą trafić w siebie w oknie szerokim na około sześć instrukcji maszynowych. To nie jest coś, co widać, czytając kod linijka po linijce. To jest sekwencja zdarzeń w czasie, którą trzeba sobie wyobrazić — a wyobrażenie sobie splotu dwóch wątków trafiających w mikroskopijne okno to zupełnie inne zadanie niż wypatrzenie błędu zapisanego wprost w składni.

Po drugie — brak śladów. Gdy pierwszy błąd z tej łatki został załatany, można było przypuszczać, że drugi się ujawni. Ale Bad Epoll ma cechę, która czyni go niemal niewidzialnym: uszkodzenie pamięci, które wywołuje, zwykle nie wyzwala KASAN — głównego narzędzia jądra do wykrywania błędów pamięci. Nie zapala się żadna lampka. Nie ma śladu w runtime, na którym mógłby się zaczepić automat. Błąd istnieje, ale nie zostawia sygnału, który powiedziałby skanerowi „popatrz tutaj".

Złóż te dwie rzeczy razem, a otrzymasz precyzyjny portret ślepego pola. AI świetnie radzi sobie z tym, co jest zapisane w kodzie — ze strukturą, składnią, wzorcami, które da się przeczytać. Gorzej radzi sobie z tym, co istnieje wyłącznie w czasie wykonania: z sekwencją zdarzeń, która nie jest widoczna w żadnej pojedynczej linijce, tylko w ich splocie w konkretnym mikromomencie. Squid i Redis, które opisywaliśmy, były błędami statycznymi — leżały w kodzie jak literówki, czekając, aż ktoś dość uważny je przeczyta. Bad Epoll nie leży w kodzie. Leży pomiędzy dwiema instrukcjami wykonywanymi równolegle. I to jest różnica, która oddziela to, co maszyna łapie, od tego, co mija.

Uczciwie: to nie jest historia o słabym AI

Zanim wyciągniemy z tego zbyt szeroki wniosek, trzeba nazwać dwie rzeczy wprost — bo inaczej ten wpis stałby się dokładnym lustrzanym odbiciem hype'u, przed którym sami przestrzegaliśmy.

Pierwsza: znalezienie przez Mythos pierwszego błędu z tej łatki było prawdziwym osiągnięciem, nie przypadkiem. Race condition są trudne do wykrycia dla każdego — dla człowieka też. AI wykryło jeden z pary, w której drugi wymknął się i jemu, i wcześniejszym ludzkim przeglądom kodu przez dwa lata. To nie jest opowieść „maszyna zawiodła". To opowieść „maszyna ma inny profil mocnych i słabych stron niż człowiek" — i po raz pierwszy widzimy ten profil na konkretnym przykładzie, zamiast się go domyślać.

Druga: ten sam typ trudności, który sprawił, że AI przeoczyło Bad Epoll, sprawił też, że błąd był trudny na każdym etapie. Trudny do znalezienia. Trudny do naprawienia — pierwsza łatka nie wystarczyła, a poprawna wersja zajęła około dwóch miesięcy dopracowywania. Trudny do wyeksploatowania — okno sześciu instrukcji trzeba trafić niezawodnie. Chung zbudował exploit o skuteczności około dziewięćdziesięciu dziewięciu procent, działający nawet z wnętrza sandboxa renderera Chrome, który blokuje niemal wszystkie inne błędy jądra. To pokazuje, że race condition nie jest „łatwym błędem, który AI z lenistwa pominęło". Jest błędem z gatunku najtrudniejszych, i akurat na tym gatunku maszyna potyka się bardziej niż człowiek.

I żeby domknąć obraz uczciwie: to nie znaczy, że AI przestało znajdować prastare błędy. W tym samym okresie Mythos wykrył siedemnastoletnią lukę zdalnego wykonania kodu w implementacji NFS w systemie FreeBSD. Zdolność, którą opisujemy od Squida, jest realna i nie słabnie. Bad Epoll nie odbiera jej. Dokłada do niej granicę — pokazuje, że obok obszaru, w którym maszyna jest znakomita, istnieje sąsiedni obszar, w którym jest ślepa. I dopiero znając oba, można kalibrować oczekiwania uczciwie.

Co z tego wynika dla obrońcy

Pierwszy wniosek jest praktyczny i pilny, choć nie alarmowy. Bad Epoll jest załatany — jedyną rozsądną reakcją jest zaktualizowanie jądra na wszystkim, co go używa, ze szczególną uwagą na węzły, na których uruchamiacie niezaufany kod, bo exploit działa nawet spod sandboxa przeglądarki. Nie ma śladów wykorzystania tej luki w realnych atakach i nie trafiła na listę aktywnie eksploatowanych. To jest naprawa prewencyjna, nie gaszenie pożaru.

Drugi jest strategiczny i wykracza poza tę jedną lukę. Jeśli budujesz obronę wokół założenia, że AI przeskanuje twój kod i znajdzie w nim luki — a to założenie jest coraz powszechniejsze — musisz wiedzieć, że to skanowanie ma kształt. Nie jest równomierne. Łapie błędy statyczne, zapisane w składni, i robi to znakomicie. Ale błędy współbieżności, wyścigi, uszkodzenia pamięci bez śladu w runtime — to jest obszar, w którym maszyna wciąż potyka się bardziej niż wyspecjalizowany człowiek. Praktyczna konsekwencja: przegląd kodu wspierany przez AI nie zwalnia z ludzkiego audytu ścieżek współbieżnych. Wręcz przeciwnie — skoro wiemy, że tam właśnie maszyna widzi najsłabiej, to tam ludzka uwaga jest najcenniejsza.

Trzeci jest najszerszy i dotyczy tego, jak w ogóle myślimy o roku, który opisujemy. Cała nasza trajektoria od kwietniamówiła o jednym kierunku: zdolności AI rosną, okno się zamyka, przeciwnik dostaje te same narzędzia co obrońca. To wszystko jest prawdą. Ale Bad Epoll dokłada niezbędny przypis: te zdolności nie są jednolitą ścianą, która równo posuwa się do przodu. Mają teksturę — obszary, gdzie są już nadludzkie, i sąsiednie obszary, gdzie wciąż są ślepe. Obrońca, który zna tę teksturę, wie, gdzie postawić maszynę, a gdzie człowieka. Obrońca, który zakłada jednolitą wszechmoc AI, zostawia odsłonięte dokładnie te miejsca, których maszyna nie pokrywa.

Jedna myśl na koniec

Przez cały ten rok pytanie brzmiało, jak szybko AI dogoni i przegoni człowieka w znajdowaniu luk. Bad Epoll pokazuje, że to złe pytanie — bo zakłada jeden wyścig na jednej prostej. A tu są dwa różne tory. Na jednym — kodzie statycznym, prastarych błędach zapisanych w składni — maszyna już wygrała i nie oddaje prowadzenia. Na drugim — wyścigach, oknach szerokich na sześć instrukcji, błędach istniejących tylko w splocie czasu — wciąż prowadzi człowiek, i to nie z sentymentu, lecz dlatego, że potrafi wyobrazić sobie sekwencję, której w kodzie nie widać. To jest, na razie, ostatni bastion. Ale ważniejsze od tego, jak długo się utrzyma, jest to, że po raz pierwszy wiemy dokładnie, gdzie on leży — a wiedza, gdzie maszyna nie patrzy, jest dziś warta tyle samo, co wiedza, co maszyna potrafi znaleźć.

Źródła

The Hacker News — szczegółowa analiza Bad Epoll, z potwierdzeniem wspólnego pochodzenia obu błędów z łatki z 2023 roku, wyjaśnieniem okna sześciu instrukcji i braku sygnału KASAN oraz cytatami badacza: https://thehackernews.com/2026/07/new-bad-epoll-linux-kernel-flaw-lets.html

Google kernelCTF — zgłoszenie Bad Epoll jako zero-day wraz z pełnym opisem technicznym exploita i jego skuteczności z wnętrza sandboxa Chrome (badacz Jaeyoung Chung).

Rodzina błędów jądra „Bad" (Bad Binder, Bad IO_uring, Bad Spin, Bad Epoll) — kontekst serii podatności współbieżnościowych w jądrze Linuksa opisywanych przez badaczy bezpieczeństwa.