Во-первых, мы сразу позиционируем LKRG как bypassable by design и как предоставляющий лишь спорную security through diversity. Именно об этом говорится в анонсе по ссылке из новости здесь.

Во-вторых, с другой стороны, не каждая уязвимость в ядре и не каждый ее exploit приводит именно/сразу к RCE. Возможны ситуации, когда атакующему доступна попытка записи от имени и в адресное пространство ядра с какими-либо ограничениями или доступны лишь отдельные bit flips (как в случае с Rowhammer). В этих случаях у LKRG есть шанс (но не гарантия) распознать проблему до того как атакующий выполнит следующие шаги атаки.

В-третьих, из-за LKRG exploit'ы могут усложняться, а их надежность снижаться. В приведенном примере с пересчетом хешей, потребуется сначала найти их и ключ для SipHash (который генерируется случайно при загрузке модуля). Думаю, сейчас это, уже имея RCE, сделать не сложно - мы пока не пытались скрыть расположение этих переменных. Также, думаю есть более простые и надежные способы обхода текущей версии LKRG. Мы пока не решили будем ли развивать проект в сторону борьбы с обходами (чтобы повысить сложность и снизить надежность exploit'ов всё равно обходящих LKRG) или же, наоборот, решим еще более ограничиться security through diversity (позволяя любому желающему легко и надежно обходить LKRG, но зато упростив и сделав более быстрым и надежным код LKRG). Может быть, это будут две ветки разработки.