Respond to Dirty Frag

Priority order below matches how major vendors and CERTs frame response: ship supported kernel fixes, tighten local access controls, and only then consider module-level workarounds that may break legitimate network or filesystem features.

1. Patch the kernel through your distro

Apply the security-maintained kernel build for your release. Verification steps live on Detect; authoritative fix tables are on each distribution's CVE tracker (see Distros).

2. Reduce privileged local footprint while patching

• Ensure only trusted principals obtain interactive shells or workload APIs that amount to local code execution.
• Review containers for escapes-to-host primitives; remediations still require a patched host kernel.

3. Interim mitigations (vendor-aligned only)

Canadian Cyber Centre bulletin AL26-011 discusses layered exposure reduction (for example restricting availability of vulnerable paths while patches propagate). Canonical's remediation article walks through Ubuntu-specific guidance including kernel updates and discusses scenarios where unloading modules might be considered when features are unused (Ubuntu Dirty Frag fixes blog).

Expect trade-offs: ESP functionality backs many IPsec VPN deployments; RxRPC underpins Kerberos-oriented AFS workloads. Document approvals before altering modprobe blacklist entries or equivalent.

4. Monitoring and governance inputs

Feed authoritative CVE metadata into CMDB / ticketing: CVE-2026-43284, CVE-2026-43500. Third-party detection guidance from reputable vendors can augment instrumentation but must not replace vendor patch tracking; examples linked from Sources.