Jádro Linuxu 7.3 opravuje v eCryptfs chyby staré až dvacet let

Správce eCryptfs Tyler Hicks poslal 20. srpna 2026 Linusi Torvaldsovi žádost o převzetí jedenácti záplat a druhý den je Torvalds zařadil do vývojové řady 7.3. Balík je malý, sedm souborů a 73 přidaných řádků, ale osm z těch jedenácti oprav je označeno pro starší udržované řady jádra a tři z nich odkazují na commit z října 2006, kterým eCryptfs do jádra vůbec přišel.

Šifruje se soubor po souboru, ne celý oddíl

eCryptfs není šifrování disku. Je to takzvaný stacked filesystem: leží nad běžným souborovým systémem a ke každému otevřenému souboru drží dvojici. Dole je šifrovaný soubor, který se opravdu zapisuje na disk, nahoře je čitelný obsah, jaký vidí program. Klíče jsou dva, jeden na obsah a druhý na jména souborů, a hlavička spodního souboru nese metadata o tom, jak se má obsah odemknout.

Právě proto se s eCryptfs počítalo tam, kde je potřeba oddělit uživatele na společném úložišti. Návrhová dokumentace Chromium OS popisuje uložení dat každého účtu do vlastního trezoru, který se při přihlášení připojí přes eCryptfs. Ubuntu na něm postavilo šifrování domovského adresáře a balík ecryptfs-utils je v repozitáři dodnes, včetně vydání 26.04 LTS.

Klíč se vejde do 64 bajtů, dešifrovalo se jich až 512

Nejvážnější položka balíku má jediný nový test na deset řádků. Hlavička spodního souboru obsahuje paket typu Tag 3 a v něm údaj o délce zašifrovaného klíče. Parser tu délku porovnával se stropem 512 bajtů, jenže funkce, která klíč vzápětí dešifruje, zapisuje výsledek do pole dlouhého 64 bajtů. Autor opravy, který v jádře vystupuje pod jménem HanQuan, popisuje v komentáři k záplatě dva zápisy za koncem: šifra přeteče do okolní struktury a následné kopírování klíče přepíše inicializační vektor, seznam podpisů klíčů a zámky.

Podvržený soubor se musí otevřít. Víc není potřeba a stačí k tomu běžný účet. Podmínkou je AES-192; ta šifra si nastavuje délku klíče na 24 bajtů nezávisle na údaji z hlavičky, takže kontrola v kryptografické vrstvě projde, i když je deklarovaná délka mimo rozsah. Hicks k opravě doplnil, že cesta pro klíče z certifikátů tutéž kontrolu měla už dřív; chyběla jen tam, kde se klíč odemyká heslem.

Chybu nahlásily dvě strany nezávisle na sobě

Deset dní poté, co HanQuan záplatu poslal, dorazila do konference druhá oprava téže chyby. Jay Vadayath k ní přiložil výpis z KASAN, tedy z nástroje, kterým jádro hlídá zápisy mimo přidělenou paměť, a napsal, že chybu našla triážní linka firmy Artiphishell. Ta firma vyrostla z týmu Shellphish, který pod stejným jménem soutěžil ve finále AI Cyber Challenge agentury DARPA. Nástroj podle Vadayathe nezůstal u nálezu a vyrobil program, který ten výpis spolehlivě vyvolá na neopraveném jádře.

Samotnou záplatu psal jazykový model. Vadayath ji označil hlavičkou Assisted-by: Claude:claude-opus-4-7 a v průvodním textu to napsal ještě jednou otevřeně. Hicks mu poděkoval a odmítl: chybu už měl nahlášenou a do větve pustil HanQuanovu verzi, protože ta ořezává délku dřív, přímo v parseru. Do jádra tak z toho běhu doputovala reprodukce a potvrzení, ne kód. Kolik takových hlášení stojí za sadami záplat jinde, ukázala rekordní červencová sada Microsoftu.

Zbytek míří na parser a na rouru k démonu

Sedm z jedenácti oprav napsal Yichong Chen. Tři z nich tvoří jednu sérii a řeší, že funkce na čtení paketů si počítala zbývající místo v hlavičce z konstanty PAGE_SIZE mínus osm bajtů. U hlaviček verze 1 začíná sada paketů dál, takže si funkce myslela, že má víc místa, než dostala. Nově dostane skutečnou délku od volajícího a po každém přečteném paketu si ji přepočítá. Dvě ze tří záplat série odkazují právě na commit z roku 2006.

Druhá skupina míří na rouru mezi jádrem a pomocným procesem v uživatelském prostoru, přes kterou se předávají klíče. Pengpeng Hou z čínské akademie věd našel, že zápis do toho zařízení vždycky kopíruje dva bajty délky, i když zpráva nese jen jeden – u šestibajtové zprávy tedy jádro přečte bajt za koncem uživatelské paměti. Dvě další záplaty téže oblasti drží zámek při úklidu fronty a uvolňují kontext zprávy, když se odeslání nepovede.

Zbývající tři položky bezpečnost neřeší: výpis voleb pro šifrování jmen souborů ve výpisu připojených svazků, přechod na filemap_dirty_folio() a vypuštění jedné zbytečné alokace při zápisu velikosti souboru. Hicks u celého balíku uvádí, že prošel stromem linux-next a testy z projektu ecryptfs-utils, jenže opravy roury k démonu si musel ověřit ručně: na tuhle část kódu žádné testy nejsou.

Že se v dlouho zavedeném kódu najde chyba, která tam byla od začátku, není v jádře nic mimořádného – letos v srpnu tudy prošel i šest let starý únik z virtuálního stroje ve vrstvě KVM. Zvláštní na eCryptfs je poměr: jedenáct záplat na součást, ke které za posledních deset let skoro nikdo nesáhl, a osm z nich putuje i do starších řad.