A Linux titkosítási alrendszerében eltávolítják a támogatást zero-copy a felületről AF_ALG algoritmus típusokhoz SKCIPHER és AEAD. A változtatás már a cryptodev fában van, és várhatóan a következő egyesítési ablakban kerül elküldésre Linux 7.2, amely júniusban kerül megnyitásra. A döntést a zero-copy mechanizmusok körüli növekvő biztonsági aggodalmak indokolták, különösen a Linux titkosítási kódjában megjelenő legutóbbi sebezhetőségek után.
AF_ALG — ez felhasználói felület a Linux kernel titkosító API-jához. Ezen keresztül a programok hozzáférhetnek a titkosítási, hash és AEAD algoritmusok kernelbeli megvalósításaihoz, mint socketekhez. A Linux dokumentáció külön leírja az AF_ALG zero-copy üzemmódját a splice() és vmsplice() funkciókon keresztül, amely lehetővé teszi, hogy a kernel minimalizálja az adatok fölösleges másolását a kernel memóriájába.
A probléma az, hogy az AF_ALG esetében ez a teljesítményjavulás nem volt annyira lényeges, míg a kockázatok túl magasak. A változtatás szerzője, a Linux titkosítási alrendszerének fejlesztője, Eric Biggers a Google-tól, megjegyezte, hogy a zero-copy lehetővé teszi a felhasználói térből való titkosítási műveletek közvetlen végrehajtását az oldal cache fájljaim, például a su binárisan, valamint TOCTOU sebezhetőségeket teremt, amikor a memória párhuzamosan módosulhat a rajta végrehajtott művelet során.
Más szavakkal, a mechanizmus, amely hasznos a hálózati vagy fájlbevitelnél, az AF_ALG esetében túl veszélyes optimalizálásnak tűnik. Maga az AF_ALG a fejlesztő szavai szerint most elsősorban a visszafelé kompatibilitás érdekében marad fenn egy kis programkészlet számára, például az iwd számára, amelyek még nem lettek áthelyezve a felhasználói térbeni titkosításra. Eredetileg az AF_ALG-t a hardveres titkosító gyorsítókhoz való hozzáférésre tervezték, de a gyakorlatban nem bizonyult túl hatékony interfésznek erre a feladatra.
Fontos megjegyezni, hogy nem a splice() vagy a sendfile() teljes eltávolításáról van szó az AF_ALG számára. A változtatást "laza törésnek" írják le: az AF_ALG kérésekbe való adatátvitel a splice() és a sendfile() használatával továbbra is működni fog, de a kernel most már belső stabil másolatot készít az adatokból a titkosítási művelet előtt. A teljesítmény egyes esetekben csökkenhet, viszont a felhasználói API formálisan továbbra is működőképes marad.
Külön kiemelik, hogy az AF_ALG-ból a zero-copy el fog tűnni skcipher és aead. Támogatás a típus számára hash külön fogják megvizsgálni.
A módosítás háttere kellemetlen. Április végén egy sebezhetőség került napvilágra. Másolási hiba (CVE-2026-31431) az algif_aead-ben, vagyis pontosan a felhasználói kriptográfiai interfészen, az AF_ALG-on. A kutatók kimutatták, hogy az AF_ALG, a splice() és az AEAD-feldolgozás sajátosságai kombinációjával nem privilegizált felhasználók tudták megsemmisíteni a page cache-t, beleértve a setuid binárisoknak megfelelő oldalakat, ezzel emelve a privilégiumokat root szintre.
Megjelenés Másolási hiba kapcsolatban állt a 2017-es optimalizálással, amely az AEAD-műveleteket "helyben" való feldolgozásra fordította; a fájl splice() átvitele az AF_ALG-on keresztül a kernelt nem másolatokkal, hanem a page cache oldalaira mutató hivatkozásokkal működtette. Ennek következtében egyes, csak bemeneti adatként kezelt adatok a felírandó scatterlistbe kerülhettek.
A zero-copy eltávolítása az AF_ALG-ból nem egyetlen sebezhetőség pontos javítása. Inkább egy osztálynyi kockázatos forgatókönyv eltávolítására tett kísérlet a ritkán használt UAPI-ból, ahol az optimalizáció előnyei nem indokolják a bonyolultságot és a potenciális következményeket. A szokásos felhasználók számára a változtatás valószínűleg észrevétlen marad; a ritkán használt programok esetében, amelyek aktívan használják az AF_ALG-ot splice() vagy sendfile() révén, a teljesítmény csökkenhet a további másolás miatt.
Forrás: linux.org.ru
