Et certainement d'autres à venir dans un futur proche, vu qu'il y a beaucoup de recherches de vulnérabilités et de production d'exploits sur ce sujet précis ces temps-ci... peut-être même que certaines vulnérabilités de la même classe sont déjà en cours de traitement en privé

Contrairement à celle de Copy Fail, la mitigation de Dirty Frag à base de modprobe, sur les machines où ces modules ne sont pas utilisés par un logiciel légitime, fonctionne sur la grande majorité des distros. C'est bête que les distros enterprise (TM) aient trouvé malin de compiler algif_aead en dur dans le kernel.
D'après ce que j'ai lu, l'exploit fourni pour Dirty Frag utilise les unprivileged user namespaces, une énorme passoire (historiquement, des dizaines de LPE, et encore des facilitations d'exploit comme ici) que je désactive depuis des années sur toutes les machines perso et pro. Mais ça ne veut pas nécessairement dire qu'on ne peut pas faire un autre exploit qui n'utiliserait pas ça...
Comme souvent, grsecurity comporte une fonctionnalité - ici MODHARDEN - qui, quand elle est activée, limite l'auto-loading de modules causé par la demande d'ouverture de socket d'un type donné par un utilisateur non privilégié, et donc, aide à se défendre des vulnérabilités dont il est question ici, si elles sont présentes sous forme de module et non built-in.