Added dirtyfrag module by nickanderson · Pull Request #143 · cfengine/modules

nickanderson · 2026-05-13T19:15:52Z

No description provided.

Detects Dirty Frag kernel page-cache write vulnerabilities (xfrm-ESP and RxRPC) and optionally applies mitigation via modprobe.d module blacklisting.

oldgiova

I've asked Claude Code to helping me review this and here's the finding (the ones that I understood and confirmed with human double-checks)

oldgiova · 2026-05-14T19:32:38Z

+        "# Dirty Frag CVE-2026-43284 mitigation: block xfrm-ESP and IPComp$(const.n)",
+        "install esp4 /bin/false$(const.n)",
+        "install esp6 /bin/false$(const.n)",
+        "install ipcomp4 /bin/false$(const.n)",


Maybe you have to drop the 4?

"install ipcomp /bin/false$(const.n)",

oldgiova · 2026-05-14T19:33:20Z

+# Dirty Frag CVE-2026-43284 mitigation: block xfrm-ESP and IPComp
+install esp4 /bin/false
+install esp6 /bin/false
+install ipcomp4 /bin/false


Same here: maybe you have to drop the 4?

oldgiova · 2026-05-14T19:49:57Z

+      or => {
+        "_esp_conf_exists",
+        "_userns_conf_exists",
+        "!_userns_enabled",


RedHat/SUSE have /proc/sys/kernel/unprivileged_userns_clone, so !_userns_enabled is always true, so _esp_mitigated is true. The consequence is that every RHEL/SLES host with esp4.ko on disk are listed as mitigated always.

Maybe probe user.max_user_namespaces instead as an evidence of mititagion?

oldgiova · 2026-05-14T20:10:05Z

+
+    # --- Read the unprivileged user namespace setting ---
+    "_ns_val"
+      string => readfile("${_ns_proc}"),


readfile() does not strip trailing newlines, so the comparison is false even if the file exists. Maybe use sysctlvalue() ?

vars: "_max_userns" string => sysctlvalue("user.max_user_namespaces"); classes: "_userns_disabled" expression => strcmp("0", "${_max_userns}");

Then in _esp_mitigated, drop the userns leg entirely, and fold it into the vulnerability condition instead:

"dirtyfrag_esp_needs_mitigation" and => { "dirtyfrag_esp_present", "!_userns_disabled", "!_esp_mitigated" };

oldgiova · 2026-05-14T20:12:11Z

+    # patched version comes first (or equal) in version-sorted order.
+    # printf '%s\n' "$patched" "$running" | sort -V | head -1
+    # If result == patched, then running >= patched.
+    "_esp_kernel_patched"


These classes are not passed by default in main, so you should widen the scope, right?

oldgiova · 2026-05-14T20:20:56Z

+    {
+      "label": "RHEL/CentOS/Alma/Rocky/OL 8",
+      "id_match": "^(rhel|centos|rocky|almalinux|ol)$",
+      "version_match": "^8",


This doesn't match 8.10 is it?

craigcomstock

looks good. :)

craigcomstock · 2026-05-15T17:02:06Z

+  - `NOT AFFECTED` -- vulnerable modules not present on this host
+- **Dirty Frag CVE-2026-43500 (RxRPC) status**:
+  - `VULNERABLE (rxrpc loaded)` -- module currently in memory
+  - `VULNERABLE (module on disk, not loaded)` -- module present but not loaded; latent risk


this is the same as the above, should have some differentiation to know which CVE is "module on disk, not loaded".

craigcomstock · 2026-05-15T17:03:26Z

+- **Dirty Frag CVE-2026-43500 (RxRPC) status**:
+  - `VULNERABLE (rxrpc loaded)` -- module currently in memory
+  - `VULNERABLE (module on disk, not loaded)` -- module present but not loaded; latent risk
+  - `PATCHED (kernel fix applied)` -- running kernel version includes the fix (auto-detected or admin-declared)


ah, maybe the inventory name is the name of the CVE and the values what you are enumerating here... in that case the values should NOT include any mention of the CVE and maybe even not include comments so that they are more easily queried for just the CAPS portion.

craigcomstock · 2026-05-15T17:04:40Z

+
+This blocks the ESP/IPComp exploit path without blacklisting the modules, preserving IPsec functionality. Use this instead of `mitigate_esp` on hosts that require IPsec. Note: this does **not** mitigate CVE-2026-43500 (RxRPC) and may break rootless containers (Podman, Docker rootless), Flatpak, and browser sandboxes. Applied via `sysctl --system` on first write.
+
+All mitigations are **disabled by default** -- the module only reports status unless the corresponding CMDB variable is set to `"true"`.


what is the CMDB variable name?

craigcomstock · 2026-05-15T17:11:13Z

+    # If result == patched, then running >= patched.
+    "_esp_kernel_patched"
+      expression => returnszero(
+        "/usr/bin/test \"$(const.dollar)(/usr/bin/printf '%s\n' '${_esp_patched_ver}' '$(default:sys.release)' | /usr/bin/sort -V | /usr/bin/head -1)\" = '${_esp_patched_ver}'",


maybe use paths here to avoid trouble with OS different paths to these common commands? You are already specifying useshell so might as well remove the full paths to the commands for flexibility sake.

craigcomstock · 2026-05-15T17:11:57Z

+
+    "_rxrpc_kernel_patched"
+      expression => returnszero(
+        "/usr/bin/test \"$(const.dollar)(/usr/bin/printf '%s\n' '${_rxrpc_patched_ver}' '$(default:sys.release)' | /usr/bin/sort -V | /usr/bin/head -1)\" = '${_rxrpc_patched_ver}'",


remove full paths to executables, useshell is in effect.

craigcomstock · 2026-05-15T17:15:05Z

+    "kernel_patch_check" usebundle => "dirtyfrag:kernel_patch_check";
+
+  vars:
+    # --- Constants ---


probably remove this comment, these are not constants in language terms though they may be in effect such things in usage. 99% of vars in cfengine policy language are vars right? even though you can redefine them at will.

craigcomstock · 2026-05-15T17:17:52Z

+      string => ifelse(
+        "dirtyfrag_esp_needs_mitigation._esp_any_loaded",
+        "VULNERABLE (${_esp_loaded_names} loaded)",
+        "dirtyfrag_esp_needs_mitigation",
+        "VULNERABLE (modules on disk, none loaded)",
+        "dirtyfrag:kernel_patch_check._esp_kernel_patched|_esp_admin_patched",
+        "PATCHED (kernel fix applied)",
+        "dirtyfrag_esp_present._esp_mitigated",
+        "MITIGATED (blacklist in place)",
+        "NOT AFFECTED"
+      );
+
+    "_rxrpc_status"
+      string => ifelse(
+        "dirtyfrag_rxrpc_needs_mitigation._rxrpc_loaded",
+        "VULNERABLE (rxrpc loaded)",
+        "dirtyfrag_rxrpc_needs_mitigation",
+        "VULNERABLE (module on disk, not loaded)",
+        "dirtyfrag:kernel_patch_check._rxrpc_kernel_patched|_rxrpc_admin_patched",
+        "PATCHED (kernel fix applied)",
+        "dirtyfrag_rxrpc_present._rxrpc_mitigated",
+        "MITIGATED (blacklist in place)",
+        "NOT AFFECTED"
+      );


for all of these I mentioned in the README that maybe simpler values would be easier to see and query and the inventory NAME will convey which CVE is in play for that value so no need to repeat it in the value.

craigcomstock · 2026-05-15T17:19:52Z

+
+  classes:
+    # --- CMDB toggles ---
+    "_mitigate_esp" expression => strcmp("true", "$(mitigate_esp)");


why vars with value "true" instead of classes in CMDB? It would seem that classes would make more sense. Maybe add a note here that you use variables instead of classes because you want to enable global settings like groups for all devices and then override individual hosts with CMDB values other than true. We can't specify CMDB data that REMOVES a class so this workaround is needed. Right?

Yeah, it was at least concern about shadowing and not overriding classes to false that drove me towards a variable here.

craigcomstock · 2026-05-15T17:21:25Z

+    "_ipcomp6_on_disk" expression => fileexists("${_ipcomp6_path}");
+
+    # Compressed variants (.ko.zst, .ko.xz)
+    "_esp4_on_disk_z" expression => fileexists("${_esp4_path}.zst");


I suppose you could have iterated on these bits, supplying an slist of suffixes of [ .ko, .ko.zst, .ko.xz ]

Yeah, could have.

craigcomstock · 2026-05-15T17:25:01Z

+
+  commands:
+    # --- Unload ESP/IPComp modules after conf written ---
+    _mitigate_esp.dirtyfrag_esp_conf_repaired::


are you going to miss things sometimes if only when _repaired? Maybe a kernel module promise would be better... promise that these are not loaded.

I don't love the overhead of custom promise types. semantically reading is way nicer, but it's a bit of yeuck for me every time i think about custom promises that would be backed with an interpreter.

but yes, keying on just repaired can miss stuff. Better to not key off indirect state and keyu off fact that module is loaded and mitigation is desired.

nickanderson · 2026-05-15T17:53:22Z

Thanks for the reviews, great stuff. I am working on an overhaul

nickanderson requested a review from olehermanse May 13, 2026 19:16

nickanderson force-pushed the security/dirtyfrag branch 2 times, most recently from 4565be0 to 4bde0b0 Compare May 13, 2026 19:22

Add dirtyfrag module for CVE-2026-43284 and CVE-2026-43500

98fde78

Detects Dirty Frag kernel page-cache write vulnerabilities (xfrm-ESP and RxRPC) and optionally applies mitigation via modprobe.d module blacklisting.

nickanderson force-pushed the security/dirtyfrag branch from 4bde0b0 to 98fde78 Compare May 13, 2026 19:24

oldgiova reviewed May 14, 2026

View reviewed changes

craigcomstock reviewed May 15, 2026

View reviewed changes

nickanderson marked this pull request as draft May 15, 2026 17:52


		This blocks the ESP/IPComp exploit path without blacklisting the modules, preserving IPsec functionality. Use this instead of `mitigate_esp` on hosts that require IPsec. Note: this does not mitigate CVE-2026-43500 (RxRPC) and may break rootless containers (Podman, Docker rootless), Flatpak, and browser sandboxes. Applied via `sysctl --system` on first write.

		All mitigations are disabled by default -- the module only reports status unless the corresponding CMDB variable is set to `"true"`.

Conversation

nickanderson commented May 13, 2026

Uh oh!

oldgiova left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oldgiova May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

craigcomstock left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nickanderson commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

oldgiova May 14, 2026 •

edited

Loading