What breaks when Dirty Frag module blocking is not in place?

Why the blocklist has to cover every affected kernel module

Dirty Frag style mitigation only works if the kernel can no longer load the module family that preserves the exploit path. In this case, leaving esp4, esp6, ipcomp4, ipcomp6 or rxrpc loadable means the attacker still has a route into a writable kernel path, even when earlier blocking was thought to be sufficient. The important point is scope, not just a single module name.

That is why partial blocking often creates a false sense of closure. If one affected module remains available, the attack chain can survive by shifting to another subsystem that offers the same underlying kernel write primitive.

What the attacker is really relying on

The abuse is not limited to a single code path. The practical weakness is that the exploit class can pivot across multiple modules, so a defender who blocks only one interface may leave an equivalent entry point exposed. From an attacker’s perspective, that makes the environment more durable than the mitigation report suggests.

CIS Benchmarks are useful here because the real control objective is to remove the reachable attack surface, not merely to harden one visible path.

Once a writable kernel path remains reachable, the consequence is not just a failed mitigation. It becomes a privilege-escalation opportunity with system-wide impact, because kernel compromise changes the trust model for every process on the host.

How to confirm the mitigation actually took effect

Validation should focus on module availability, not just configuration intent. If the affected modules can still be loaded after the mitigation is applied, the host is still exposed. That means the operational question is whether the block was enforced at boot, persisted across reboots, and applied to every affected subsystem consistently.

For control mapping, a kernel exposure like this fits the logic of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around configuration management, access restriction and integrity-focused safeguards. The practical test is whether the control prevents the vulnerable module from becoming reachable again.

If you are validating from a hardening perspective, also check whether the mitigation was applied only to the immediate exploit path or to the entire family of loadable modules that preserve the same effect. A narrow fix can leave the same risk in place under a different name.

Practitioner Guidance

What to prioritise: Treat residual module loadability as an exposure finding, not as a theoretical edge case. The first priority is to verify that every affected module family is actually blocked on the running host, across reboot and any automation that may reintroduce it.

What to verify: Confirm the blocked state at the kernel and orchestration layers, then test that no alternate module in the same exploit chain remains loadable. If the mitigation depends on local configuration only, assume it is weaker until you can prove persistence.

Decision rule: If any of the affected modules can still be loaded, assume the host is still exploitable until proven otherwise. If the host was exposed while the block was incomplete, escalate to compromise review before declaring the fix successful.

Practitioner takeaway: The meaningful question is not whether one module was blocked, but whether the full exploit path was removed; otherwise the mitigation may look complete while the privilege-escalation route still exists.

Related resources from NHI Mgmt Group

• What breaks when a Linux kernel flaw like Dirty Frag is not patched?
• What breaks when PHI blocking is not in place for cloud file collaboration?
• What breaks when runtime exploit blocking is not in place for production apps?
• What breaks when orphaned machine identities are left in place?