"a bug triggerelesenek a pillanataban a userland taszk el es virul (a kernel epp visszaterni keszult hozza, ugyebar), koszoni szepen."
Vegyél vissza az arcodból, mert el vagy tévedve. A részletek igenis számítanak, mert ha nem figyel rá az ember, úgy el fog taknyolni, mint most Te.
A bug triggelésekor szó sincs arról, hogy a kernel épp visszatérne hozzá, a userland task MÁR NEM ÉL is virul, tekintettel arra, hogy új exception (pl az általad módosított PF ISR) csak akkor hívódhat, ha a GP handler már végzett, és kivágta a hibás taskot.
1. "A" task syscall
2. "A" task sysret, GPF
3. "A" GPF handler indul (injektálás)
4. "A" GPF visszatér, de nem a meghaló taszkra
5. "B" PF hívódik, ezzel triggerelődik egy nemlétező task memóriájában egy kód... na ez epic fail
Plusz itt egy kis lista arról, amiben tévedsz még:
"> legalább 5*8 byte garbage - miert? kontrollalhato egy jo resze."
Bizonyísd be! Ezeket az értékeket a CPU helyezi a verembe, és ráadásul ebből 4 olyan regiszter, amit ugyancsak megnézek, hogy módosítasz ring3-ról.
"> rcx=garbage - kontrollalt (max nem idealis IDT entry-nek, de pl. tokeletes tetszoleges ops strukturaban fuggveny pointer felulirasara)."
Ha ezt befolyásolni tudnád, akkor az egész syscall értelmetlen lenne. Milyen jó, hogy Te okosabb vagy, mint az Intel és az AMD mérnökei együtt!
"siman felul lehet irni egy processz uid-jat."
Oké, de melyikét? Azt, amelyiket épp most lőtt ki a GP handler? :-D Muhahahaha
"es az kit erdekel? ideiglenes allapot, jol fesult exploit elso dolga visszaallitani az eredeti tartalmat"
Amit mikor is mentesz le? A syscall handler és GP handler hívás között? Muhahahahahahahahahahaha. Looser.