A Linux kernel biztonsági sérülékenységeiről szóló hírek rendszeresen felkavarják a közösséget, de időről időre érkeznek olyan hullámok, amelyek még a tapasztalt rendszergazdákat is megállítják egy pillanatra. Amikor nagyon rövid idő alatt több száz CVE (Common Vulnerabilities and Exposures) bejegyzés jelenik meg a kernelhez kapcsolódóan, az első reakció gyakran a pánik. Ugyanakkor a háttérben ennél sokkal összetettebb, technikailag érdekesebb folyamat zajlik, amely szorosan kapcsolódik az automatizált és AI-alapú biztonsági kutatáshoz.

A Linux kernel CVE-inek hivatalos bejelentéseit a linux-cve-announce levelezőlistán teszik közzé, amely a lore.kernel.org archívumában követhető. Itt a kernel biztonsági csapata és a karbantartók strukturált formában dokumentálják a sérülékenységeket, hozzárendelve a CVE-azonosítókat, a verziókat, amelyeket érint, és azokat, amelyekben már javítva lett.

A fordulópont: a kernel saját CVE-számozási hatósága

2024 elején a Linux Kernel Organization hivatalos CVE Numbering Authority (CNA) lett. Ez gyökeresen megváltoztatta a projekt hozzáállását: korábban egy CVE-t jellemzően csak akkor osztottak ki, ha egy külső kutató bejelentést tett. Az új modellben minden olyan javítást, amely elméletileg biztonsági hatással bírhat, automatikusan CVE-azonosítóval látnak el — függetlenül attól, hogy volt-e hozzá exploit vagy bejelentés.

A számok ezt egyértelműen alátámasztják. A linux-cve-announce archívum alapján:

2026 kilenc hónap alatt már meghaladta a két korábbi teljes évet — és ebből önmagában szeptemberre 2 119 CVE esett, tíz külön adagban közzétéve (szept. 3., 4., 9., 11., 16., 17., 18., 24., 25., 26-án). Egyetlen nap, szeptember 17-e alatt 602 CVE-t jelentettek be — ez majdnem annyi, mint amennyi 2024-ben egy teljes hónap alatt született.

Mit takar valójában a szeptemberi 2119 CVE?

Az érintett alrendszerek eloszlása jól mutatja, hogy nem egy központi, kritikus komponensről van szó, hanem a kernel driver- és protokoll-rétegének szinte teljes keresztmetszetéről:

A lista élén tudatosan a wifi- és USB-eszközdriverek állnak — ezek azok a kódrészletek, amelyeket viszonylag ritkán auditálnak kézzel, ugyanakkor rendkívül sok hardverváltozatot kell kiszolgálniuk, így tele vannak ritkán futó, edge-case kódágakkal.

A hibatípusok mögött az automatizált eszközök keze látszik

A szeptemberi közlemények szövegtestét kulcsszavak szerint elemezve a következő kép rajzolódik ki (2 119 bejegyzésből):

Ez a megoszlás önmagában is beszédes: a KASAN (Kernel Address Sanitizer) és a syzkaller a Google által fejlesztett coverage-guided fuzzing-infrastruktúra alapkövei. Amikor egy CVE-leírás egy nyers kernel-panic naplót tartalmaz például: „Comm: syz-executor” vagy „Not tainted syzkaller” sorral, az egyértelműen azt jelzi, hogy a hibát nem emberi code review, hanem automatizált, véletlenszerű bemenetekkel dolgozó tesztelő rendszer találta meg — méghozzá olyan mennyiségben, amit kézi triage-elés sosem tudott volna feldolgozni.

Fontos adat még: a 2 119 szeptemberi közlemény közül egyetlen egy sem tartalmaz CVSS-pontszámot. Ez nem hiányosság, hanem tudatos döntés a kernel biztonsági csapata részéről — erre a kritikák szekciójában visszatérünk.

Két konkrét eset közelről

CVE-2026-100079 (usb: typec: ucsi debugfs teardown) jól illusztrálja, hogyan néz ki egy tipikus, alacsony súlyosságú, de mégis dokumentált bejegyzés. A hiba lényege, hogy az ucsi_unregister() nem törölte a debugfs-bejegyzéseket, így egy remoteproc-újraindítást végző driver (ucsi_glink) újra létre akarta hozni ugyanazt a debugfs-könyvtárat, ami hibaüzenetet és inkonzisztens állapotot okozott. A hiba a 6.6-os kernelben lévő egyetlen commit-ra vezethető vissza, de a javítást öt különböző stabil ágban (6.6.157, 6.12.110, 6.18.52, 7.2.6, 7.3-rc1) kellett külön-külön becsomagolni — ez mutatja, miért nem lehet egyetlen "javítva" dátumot mondani egy kernel-CVE-re.

CVE-2026-98151 (bpf verifier: speculative pointer arithmetic) technikailag jóval érdekesebb eset. A BPF-verifier egy unprivilegizált program betöltésekor egy Spectre-jellegű spekulatív végrehajtási utat is szimulál (sanitize_speculative_path()), hogy kiszűrje az oldalcsatorna-alapú memóriakiolvasási kísérleteket. A hiba abból adódott, hogy a regiszterállapot pillanatképe (snapshot) egy köztes, inkonzisztens állapotban készült el — a 32 és 64 bites határértékek szinkronban tartása csúszott el egy műveletsoron belül. A rendszer saját belső ellenőrzése (reg_bounds_sanity_check()) fogta meg a problémát "REG INVARIANTS VIOLATION" figyelmeztetéssel. Ez pontosan az a fajta finomságokban rejlő, nehezen kézzel felfedezhető hiba, amelyre a verifier-fuzzing eszközök (pl. a BPF-specifikus syzkaller-modulok) kifejezetten specializálódtak.

Miért vitatott ez a megközelítés?

1. Jel-zaj viszony. Ha egy szervezet napi szinten 50-600 új kernel-CVE-ről kap értesítést, gyakorlatilag lehetetlen mindegyiket egyénileg értékelni. A fenti táblázatból is látszik: a túlnyomó többség (use-after-free egy ritkán használt wifi-driverben, debugfs-takarítási hiba) a gyakorlatban csak nagyon specifikus hardver- és konfigurációs kombináció esetén releváns.

2. Nincs CVSS-pontszám. Ahogy fentebb jeleztük, a 2026 szeptemberi 2 119 bejegyzés egyike sem tartalmaz súlyossági score-t. A kernel csapata szándékosan nem ad ilyet, mert a súlyosság erősen kontextusfüggő — ez viszont megnehezíti az automatizált priorizálást a sebezhetőség-szkennerek és compliance-eszközök számára.

3. Megfelelőségi teher. Sok szervezetnek szabályozási előírás miatt (PCI-DSS, ISO 27001) minden "kritikus" CVE-t adott időn belül kezelnie kell. Egy 10x-es CVE-szám-növekedés arányosan megnöveli az auditáláshoz szükséges munkát, gyakran olyan hibák miatt, amelyek a konkrét rendszerkonfigurációban soha nem lettek volna kihasználhatók.

Greg Kroah-Hartman és a kernel csapat álláspontja

A biztonsági csapat álláspontja: az átláthatóság hosszú távon többet ér, mint a rövid távú kényelem. Ha egy hibát javítanak, de nem dokumentálják, a régebbi kernelt futtató szervezetek sosem tudják meg, hogy ki vannak-e téve egy kockázatnak. A súlyosság megítélését tudatosan a disztribúciókra és a végfelhasználókra bízzák, akik ismerik a saját környezetüket — a kernel csapat csak a technikai tényeket (mely commit, mely verziók) dokumentálja.

Gyakorlati következmények

1. Szűrjünk konfiguráció szerint. A szeptemberi 96 wifi- és 39 USB-CVE túlnyomó része irreleváns egy headless szerverfarm esetén, amely nem tölt be ilyen modulokat.
2. Támaszkodjunk a disztribúciók saját triage-ára (Red Hat, SUSE, Ubuntu), amelyek CVSS-pontszámot és backport-státuszt is rendelnek a bejegyzésekhez.
3. Kezeljük külön a syzkaller/KASAN-eredetű bejegyzéseket (szeptemberben ez a közlemények kb. 19%-a explicit módon) — ezek jellemzően korrektségi hibák, nem aktívan kihasznált sérülékenységek.
4. Priorizáljuk a hálózatnak kitett alrendszereket (net, nfsd, bpf, KVM) a helyi, hardverspecifikus driverekkel (wifi, USB, media) szemben.

Összegzés

A szeptemberi 2 119 CVE nem azt jelenti, hogy a Linux kernel hirtelen bizonytalanabbá vált — az adatok (402 KASAN-találat, 39 explicit syzkaller-hivatkozás, nulla CVSS-pontszám) egyértelműen azt mutatják, hogy egy szisztematikusabb dokumentációs politika és az automatizált fuzzing-infrastruktúra együttes hatásáról van szó. A kihívás nem a riasztások figyelmen kívül hagyása, hanem a triage-folyamatok modernizálása: kontextusfüggő kockázatértékelés és annak elfogadása, hogy a nagyobb szám a nagyobb láthatóság ára, nem a nagyobb veszélyé.