Nem feltétlenül. Illetve nem úgy és nem azért.
Az eBPF-nél sem tetszőleges kódot injektálnak a kernelbe, hanem egy JIT fordítón keresztülmegy előtte és elég erősen sandboxolva van. Bár nem olvastam még nagyon bele, de meglepne, ha az io_uring nem az eBPF-nél már kitalált alapokra építene, hanem elkezdenék újrafeltalálni a kereket.
Ami ténylegesen bajt okozott, azok a nyomorult spekulatív CPU sebezhetőségek. Itt ugyanis elvileg teljesen hibátlan és logikailag tökéletesen sebezhetetlen kódot is lehet a támadáshoz gadget-nek használni, hiszen arra épít, hogy a CPU egy logikai kifejezés (Spectre V1 példánál maradva) kiértékelése előtt megtippeli az eredményt és annak megfelelően előredolgozik. Gyakorlatilag a kódban egy hibátlan logikai feltételt hibásan kiértékel és ezzel dolgozik tovább, aztán a végén rollbackeli az egészet, de maradnak sebességben kimutatható mellékhatások. A fejlesztők mindenféle toolokkal folyamatosan keresnek olyan kódrészleteket a kernelben, amik a támadót segítő gadgetként használhatóak lennének és körbevédik spekulációt átmenetileg letiltó utasításokkal (IPBP). Emiatt nem nagyon van gyakorlatban kihasználható spectre v1 sebezhetőség. Ha viszont user spaceből be lehet tölteni - egyébként logikailag hibátlan, sebezhetőséget nem tartalmazó - kódot a kernelbe, akkor a támadó tudhat magának gyártani saját gadget-et.
Ez ellen elvileg raktak védelmet a JIT fordítóba (link), de a másik bagázs meg azon dolgozik, hogy ezeket hogy lehet kijátszani.