32 BAJTOV, KI NISO PRIPADALI PAKETU

V odhodnem omrežnem fragmentu, ustvarjenem na gostitelju Vercelovega okolja Sandbox, so se pojavili podatki, ki jih pošiljatelj ni vključil v paket. Izvirali so iz pomnilnika fizičnega strežnika, na katerem so tekli virtualni računalniki. Linuxov omrežni sklad jih je vključil med pripravo fragmenta IPv4, potem ko je za glavo paketa štel več pomnilnika, kot ga je veljavna vsebina paketa dejansko obsegala.

PwnEscape, pozneje označen kot CVE-2026-99999, je raziskovalec Paulos Yibelo prijavil v okviru Vercelovega varnostnega izziva avgusta 2026. Vercel je 14. oktobra potrdil, da je bil iznos gostiteljskega pomnilnika ponovljen v produkcijskem okolju Sandbox. Raziskovalci so na lastnih preizkusnih sistemih pokazali še zrušitev gostitelja in izvedbo kode s privilegiji root. Ta ločitev dokazov je bistvena: javna objava ne izkazuje, da bi bili ukazi s takšnimi privilegiji izvedeni v Vercelovi produkciji. [1][2]

Podatek, ki pomeni dovoljenje za poznejši zapis

Za prenos podatkov omrežne naprave pogosto prevzamejo izračun transportnih kontrolnih vsot, s čimer razbremenijo procesor. Linux takšno opravilo opisuje tudi v strukturi sk_buff, ki predstavlja paket med prehodom skozi omrežni sklad. Stanje CHECKSUM_PARTIAL pove, da je treba kontrolno vsoto še dokončati. Polji csum_start in csum_offset določata začetek izračuna in mesto, kamor se zapiše njegov rezultat. Če naloge ne prevzame omrežna naprava, jo lahko opravi programska funkcija skb_checksum_help(). [3]

Pri pravilno sestavljenem prometu se rezultat zapiše v ustrezno polje transportnega protokola, denimo TCP ali UDP. Vrednosti v metapodatkih zato niso samo opis paketa: usmerjajo prihodnji zapis v njegov pomnilnik. PwnEscape je izkoristil možnost, da so metapodatki iz manj zaupanja vrednega okolja določali položaj zapisa, ki ni več ustrezal dejanski razporeditvi glave IPv4. Izračun sam po sebi ni bil napačen. Ranljiv je bil naslov, na katerega je operacija pozneje zapisala rezultat. [1][3]

Jedro med obdelavo prestavlja tudi pogled na paket. Okvir lahko ob prihodu vsebuje glavo povezavnega sloja, denimo Ethernet, pozneje pa se obdelava nadaljuje pri IPv4. Struktura sk_buff zato razlikuje med osnovo dodeljenega območja, trenutnim kazalcem na podatke in začetkom omrežne glave. Odmik, ki je prestal preverjanje glede na prvotni okvir, po odstranitvi povezavnih glav ni nujno veljaven glede na glavo IPv4. Tu je nastala možnost nevarnega odloženega zapisa. [1]

Dvajset bajtov, ki jih je jedro razumelo kot šestdeset

Prvi bajt glave IPv4 združuje štiribitno različico protokola in štiribitno polje IHL (Internet Header Length). IHL določa dolžino glave v štiribajtnih enotah. V raziskovalčevem primeru je bila začetna vrednost 0x45: različica 4 in dolžina pet enot, torej 20 bajtov. Paket je bil v tej obliki obdelan in preverjen. Med kasnejšo pripravo izhodnih fragmentov pa je odloženi zapis kontrolne vsote v nadzorovanem primeru prvi bajt spremenil v 0x4f. Polje IHL je tedaj označevalo petnajst enot oziroma 60 bajtov. [1]

Funkcija ip_do_fragment() je v ranljivi izvedbi dokončala odloženo kontrolno vsoto, nato pa za nadaljnjo obdelavo prebrala dolžino glave. Do fragmentacije je torej prišla drugačna vsebina od tiste, na podlagi katere je sistem že sprejel predhodne odločitve. Raziskovalcem za učinek ni bilo treba ustvariti klasične tekme dveh niti. Dovolj je bilo zaporedje predvidenih operacij, med katerimi je poznejši zapis spremenil pomen predhodno preverjenega polja. To je napaka vrste time-of-check to time-of-use (TOCTOU), izražena skozi vrstni red omrežne obdelave. [1]

V opisanem preizkusu je linearni del paketa v strukturi sk_buff obsegal 28 bajtov: 20 bajtov prvotne glave IPv4 in osem bajtov vsebine. Po spremembi polja IHL je fragmentacijska funkcija ravnala, kakor da ima pred seboj 60-bajtno glavo. Prvih osem dodatno obravnavanih bajtov je pripadalo dejanski vsebini paketa, preostalih 32 pa ni bilo del njegovih veljavnih linearnih podatkov. Pri sestavljanju izhodnega fragmenta so se lahko znašli na mestu, rezerviranem za možnosti glave IPv4, in odpotovali po omrežju. [1]

Izraz »branje zunaj meja« zahteva natančnost. Raziskava ne dokazuje nujno branja zunaj celotnega fizično dodeljenega pomnilniškega bloka. Jedro lahko za paket rezervira več prostora od njegove trenutno veljavne linearne vsebine. Nepravilnost je bila v tem, da je funkcija bajte iz tega dodatnega območja uporabila kot vsebino paketa in jih vključila v promet. Njihov izvor je bil gostiteljev pomnilnik, do katerega uporabniška koda v navideznem računalniku ne bi smela imeti vpogleda. [1]

Da bi izključili napako pri zajemu prometa, so raziskovalci primerjali kontrolni in aktivni primer ter neodvisno potrdili prejem izhodnih fragmentov. V opisani konfiguraciji so ob posamezni ponovitvi razkrili 32 bajtov. Ta številka opisuje konkretno pomnilniško razporeditev; ni univerzalna količina podatkov, ki bi jih razkrila vsaka izvedba ranljivosti. [1]

Kako daleč je napad dejansko segel

Vercel Sandbox uporablja mikrovirtualne računalnike Firecracker z ločenimi gostujočimi jedri. Uporabnik lahko v svojem okolju poganja kodo, ne sme pa zaradi tega pridobiti dostopa do jedra fizičnega gostitelja. PwnEscape je pokazal napako v omrežni poti gostiteljevega Linuxa, na katero lahko vpliva promet iz navideznega računalnika. Odločilna ranljiva komponenta ni bila implementacija hipervizorja KVM, četudi je raziskava preizkušala prav mejo med gostom in gostiteljem. [1][2]

Dokazni obseg ima tri ravni. V Vercelovi produkciji je bil prikazan ponovljiv iznos gostiteljskega pomnilnika. Zrušitev gostitelja so raziskovalci pokazali na lastni infrastrukturi. Tam so z dodatno raziskovalno verigo dokazali tudi izbrane 64-bajtne zapise v gostiteljski pomnilnik in izvedbo pomožnega programa s privilegiji root; celotno zaporedje se je ponovilo po štirih ločenih hladnih zagonih. Prva objava ne razkrije vseh podrobnosti te verige, zato sam 32-bajtni iznos še ne pomeni samodejne možnosti izvajanja kode. [1][2]

Vercel je navedel, da preizkus ni dokazal dostopa do datotek, skrivnosti ali aplikacijskih podatkov strank. S tem tveganje razkritja občutljivih podatkov ni izključeno; opredeljen je le obseg javno potrjenih dokazov. Laboratorijski uspeh celotne napadalne verige prav tako ni dokaz kompromitacije katerekoli produkcijske platforme. [2]

Popravek in meja njegovega dosega

Vzdrževalci Linuxa so napako obravnavali kot problem zaupanja v metapodatke za odloženo kontrolno vsoto. Popravek 6785011f8b16, ki ga je pripravil Michael S. Tsirkin, je dodal funkcijo ip_check_csum_start(). Ta pred dokončanjem kontrolne vsote preveri, ali je začetek izračuna postavljen za dejansko glavo IPv4. Če ni, operacijo zavrne. Preverjanje je bilo dodano na pet mest, kjer bi poznejši zapis lahko posegel v že obdelano glavo. [1][4]

Popravek je bil 8. oktobra sprejet v razvojno vejo omrežnega sklada, 14. oktobra vključen v glavno razvojno drevo, 15. oktobra pa je sledila objava CVE-2026-99999. Skupina Linux Kernel CVE Team je ranljivosti pripisala oceno CVSS 3.1 9,3 od 10, v objavi pa izvorno napako povezala s spremembo iz časa jedra 2.6.27. Priporočilo je posodobitev na ustrezno popravljeno stabilno jedro, ne ročno vključevanje enega samega popravka brez vseh spremljajočih preverjanj. [1][4]

Avtorji spremembe so hkrati poudarili, da gre za dodatno zaščito na znanih mestih nevarnega zapisa, ne za popolno preverjanje vseh vhodnih metapodatkov. Michael S. Tsirkin je 15. oktobra predstavil drugo različico širšega predloga more virtio-net csum hardening, tokrat s sedmimi spremembami. Njegov namen je neobičajne odložene kontrolne vsote dokončati že ob vstopu v sklad oziroma strožje preverjati, katera polja se sploh smejo spreminjati. Ob objavi 15. oktobra je šlo za predlog nadaljnje utrditve, zato ga ni pravilno enačiti z že sprejetim in distribuiranim varnostnim popravkom. [5]

Kaj preveriti na gostiteljih

Za upravljavca virtualizacijske infrastrukture je najprej pomembno ugotoviti, kje se paket iz manj zaupanja vrednega gosta obdeluje v gostiteljskem Linuxu. Posebej relevantni so sistemi s KVM oziroma Firecrackerjem ter omrežnimi potmi virtio-net/TAP. Varnostnega stanja zato ni mogoče oceniti samo na podlagi različice jedra v virtualnem računalniku. Preveriti je treba gostiteljsko jedro, dejansko omrežno konfiguracijo in proizvajalčeve varnostne objave. Po navedbah AlmaLinuxa, ki se sklicuje na oceno Red Hata, je težavo mogoče sprožiti tudi lokalno zunaj virtualnega računalnika. Obseg izpostavljenosti zato ni omejen samo na strežnike s hipervizorjem. [4][6][7]

Uradni zapis CVE med prvimi popravljenimi različicami posameznih vzdrževanih vej navaja 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 in 7.2.11. Te številke niso univerzalen test varnosti za vse distribucije. Debian, Red Hat, Ubuntu in drugi proizvajalci lahko popravek vključijo v svojo starejšo izdajo jedra ter ohranijo njeno osnovno različico. Veljaven dokaz je objava proizvajalca o konkretnem popravljenem paketu skupaj s stanjem dejansko zagnanega jedra. [4]

Že 16. oktobra so bile vidne razlike med distribucijami: AlmaLinux je objavil popravljene pakete za različice 8, 9 in 10, vendar sprva v preizkusnem repozitoriju. AWS je navedel, da njegove upravljane storitve Amazon EC2, AWS Lambda in AWS Fargate niso prizadete; opozorilo je namenil predvsem samostojno upravljanim okoljem KVM z ranljivo omrežno potjo. Ugotovitev za posameznega ponudnika ni mogoče posplošiti na vse oblačne storitve. [6][7]

Postopek preverjanja ima jasen vrstni red. Najprej je treba popisati gostitelje, ki izvajajo tuje ali drugače manj zaupanja vredne delovne obremenitve, in ugotoviti uporabljene omrežne vmesnike. Nato preveriti proizvajalčevo varnostno opozorilo za točno nameščeni paket jedra ter načrtovati uvedbo popravka in potreben ponovni zagon gostitelja. Po ponovnem zagonu je treba potrditi različico dejansko delujočega jedra in rezultat evidentirati. Pri upravljani storitvi mora to dokazilo zagotoviti ponudnik; posodobitev gostujočega operacijskega sistema ne dokazuje popravljenega gostitelja.

Omejevanje privilegijev in ločevanje delovnih obremenitev zmanjšujeta posledice preboja, ne odpravita pa ranljivosti jedra. Začasnih obvozov brez potrditve proizvajalca za konkretno konfiguracijo ni mogoče obravnavati kot enakovredno zaščito. Prednost ima dokazilo o popravljeni različici gostiteljskega jedra, ne splošno zagotovilo o izoliranosti virtualnih računalnikov. [4][6]

Napaka je bila v vrstnem redu

Pri PwnEscape se glava IPv4 ni spremenila zato, ker bi jo sistem že ob sprejemu napačno prebral. Spremenil jo je poznejši zapis na položaj, ki ga je določal nezadostno preverjen metapodatek. Naslednja funkcija je nato iz nove dolžine glave izpeljala obseg kopiranja, ki je presegel veljavno vsebino paketa. V tem zaporedju je mogoče razločiti tako vzrok ranljivosti kot mejo učinka, ki so ga raziskovalci javno dokazali.

Za skrbnika je najpomembnejša posledica precej konkretna: preverjanje omrežne izolacije brez stanja gostiteljskega jedra je nepopolno. Paket s 28 bajti veljavnih linearnih podatkov je v dokumentiranem primeru sprožil kopiranje 60-bajtne domnevne glave; razliko je zapolnil pomnilnik gostitelja. Tistih 32 bajtov ni poslal uporabnik virtualnega računalnika. Dodal jih je gostitelj, ko je isti paket drugič razumel drugače.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZIzvirna raziskava PWNAI o PwnEscape, Vercelova potrditev preizkusa, objava CVE in popravek Linuxovega jedra.

RAZISKAVE1

DOKUMENTACIJA6

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-10-16

Viri

1. 01PRIMARY DOCUMENTATIONPWNAI Research
   PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999)

   Oktober 2026.

   Odpri vir ↗
2. 02PRIMARY DOCUMENTATIONVercel
   Findings from the $1M Vercel Sandbox challenge

   14. oktober 2026.

   Odpri vir ↗
3. 03PRIMARY DOCUMENTATIONLinux Kernel Documentation
   Checksum Offloads

   Uradna tehnična dokumentacija jedra Linux.

   Odpri vir ↗
4. 04PRIMARY DOCUMENTATIONLinux Kernel CVE Team
   CVE-2026-99999: ipv4: validate checksum_start before completing checksum

   15. oktober 2026.

   Odpri vir ↗
5. 05PRIMARY DOCUMENTATIONMichael S. Tsirkin / Linux Kernel Archive
   [PATCH net-next v2 0/7] more virtio-net csum hardening

   15. oktober 2026; nadaljnji predlog.

   Odpri vir ↗
6. 06PRIMARY DOCUMENTATIONAmazon Web Services
   AWS Security Bulletin 2026-137-AWS

   15. oktober 2026.

   Odpri vir ↗
7. 07PRIMARY DOCUMENTATIONAlmaLinux
   PwnEscape (CVE-2026-99999): Patched kernels available in testing

   16. oktober 2026.

   Odpri vir ↗