Konkret muss man als lokaler Benutzer auf dem System Code ausführen, der die beschriebene nft_verdict_init()-Kernelfunktion mit den notwendigen (fehlerhaften) Parametern aufruft. Die erste Aufgabe für einen Angreifer besteht also darin, sich Zugang zum System zu verschaffen. Das relativiert die Brisanz dieser Lücke schon mal erheblich. Als nächstes muss er entsprechenden Code auf das System bekommen. Die nft_verdict_init()-Funktion kann man nicht einfach von der Kommandozeile aus starten - es braucht compilierten Code dafür. Die Systemprogramme, welche die Funktion normalerweise aufrufen, sind nicht geeignet die Lücke auszunutzen. Ein Angreifer muss also nicht nur Zugang zu einem User-Account auf dem Zielsystem erlangen, dieser Account muss auch das Recht haben selbstcompilierten Code auszuführen. Die einfachste Möglichkeit das zu verhindern ist es, den Eintrag für das /home Filesystem in /etc/fstab mit der Option 'noexec' zu versehen. Dann kann das Betriebssystem von diesem Datenträger keine Binaries lesen und ausführen. Für die /tmp und /var Filesysteme gilt das gleiche. Auf sicherheitskritischen Systemen sollten diese Einstellungen Standard sein.
Darüber hinaus sollten sicherheitskritische Systeme durch aktivierte selinux- bzw. apparmor-Konfigurationen gesichert sein. Diese würden jeden Versuch eines nicht dafür freigegebenen Programms, nft_verdict_init() aufzurufen, sofort unterbinden. Dafür wurden diese Sicherheitsarchitekturen entworfen: man verlässt sich nicht darauf, dass es keine Schwachstellen im Kernel gibt, sondern begrenzt die potentielle Ausnutzbarkeit solcher Schwachstellen soweit, dass ein Angreifer im Prinzip root-Zugang braucht um die Schwachstelle ausnutzen zu können, mit der er root-Zugang erlangen will. Gute Sicherheitskonzepte sind wie Zwiebeln aufgebaut: kommt der Angreifer durch die äußere Schicht, so wehrt sich die Zwiebel mit ihrem Saft und erschwert damit das tiefere Eindringen.