CNF-25994: Blacklist unused filesystem kernel modules

[sebrandon1]

Jira: CNF-25994

Summary

Add a modprobe configuration to prevent loading of 5 filesystem kernel modules
that have no legitimate use on a container host OS:

• cramfs — compressed ROM filesystem (embedded Linux only)
• freevxfs — Veritas filesystem
• hfs — legacy Mac filesystem
• hfsplus — Mac OS Extended filesystem
• jffs2 — Journalling Flash File System v2 (raw flash devices only)

These modules represent attack surface with zero functional value on RHCOS.
Disabling them is a CIS Benchmark RHEL 9 v2.0.0
Level 1 Server requirement (Section 1.1.1).

What is excluded

• squashfs — actively used by CoreOS for live PXE rootfs
• udf — used by Azure/Hyper-V Ignition for provisioning config (removed from v1 per reviewer feedback)
• usb-storage — needed for BMC virtual media and bare-metal provisioning

Precedent and evidence

Existing RHCOS module blacklisting:

• The nouveau driver blacklist already uses the same modprobe.d drop-in pattern to prevent loading an unnecessary module (BZ#1700056)

Red Hat internal adoption:

• Red Hat IT disabled cramfs on internal infrastructure for CIS/STIG compliance (STIG V-230498)

Active CVEs in these modules:

• CVE-2024-45783 — HFS+ vulnerability in grub2 filesystem code

Kernel module blacklisting on OCP in production:

• The irdma module blacklist is already deployed across telco RAN clusters to prevent E810 NIC degraded profiles — established pattern of module_blacklist on OCP SNO

Industry security guidance:

• RHIVOS (Red Hat In-Vehicle OS) conducted a formal kernel filesystem risk assessment and implemented module whitelisting, stating: "an attacker cannot load the unexpected modules into the kernel, and thus exploit security problems in kernel code that is otherwise unused"
• CoreOS tracker #249 discusses kernel module management approaches
• FCOS tracker #2152 — active discussion (May 2026) among FCOS/RHCOS maintainers on denylisting unused kernel modules by default, citing vulnerability exploitation via auto-loading. Fedora already blacklists 10 similar modules
• secureblue runs in production with all five of these modules blacklisted

Customer demand:

• Telco customers (e.g., Bell Mobility) have requested CIS-compliant kernel module controls on OCP, including module loading audit and hardening

Testing

Verified on OCP 4.22 (MNO, 3 master + 2 worker) and OCP 4.21 (SNO) that
blacklisting these 5 modules causes no functional regressions. These modules
are not loaded by default on RHCOS and have no consumers in the container
host stack.

References

• CIS Benchmark RHEL 9 v2.0.0, Section 1.1.1
• Upstream strategy analysis
• CoreOS tracker #249 — module management discussion
• [NIST SP 800-53 CM-7](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-7/) — Least Functionality

Assisted by: Claude (Anthropic)

[openshift-ci-robot]

@sebrandon1: This pull request references CNF-25994 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Jira: CNF-25994

Summary

Add a modprobe configuration to prevent loading of 5 filesystem kernel modules
that have no legitimate use on a container host OS:

• cramfs — compressed ROM filesystem (embedded Linux only)
• freevxfs — Veritas filesystem
• hfs — legacy Mac filesystem
• hfsplus — Mac OS Extended filesystem
• jffs2 — Journalling Flash File System v2 (raw flash devices only)

These modules represent attack surface with zero functional value on RHCOS.
Disabling them is a CIS Benchmark RHEL 9 v2.0.0
Level 1 Server requirement (Section 1.1.1).

What is excluded

• squashfs — actively used by CoreOS for live PXE rootfs
• udf — used by Azure/Hyper-V Ignition for provisioning config (removed from v1 per reviewer feedback)
• usb-storage — needed for BMC virtual media and bare-metal provisioning

Precedent and evidence

Existing RHCOS module blacklisting:

• The nouveau driver blacklist already uses the same modprobe.d drop-in pattern to prevent loading an unnecessary module (BZ#1700056)

Red Hat internal adoption:

• Red Hat IT disabled cramfs on internal infrastructure for CIS/STIG compliance (STIG V-230498)

Active CVEs in these modules:

• CVE-2024-45783 — HFS+ vulnerability in grub2 filesystem code

Kernel module blacklisting on OCP in production:

• The irdma module blacklist is already deployed across telco RAN clusters to prevent E810 NIC degraded profiles — established pattern of module_blacklist on OCP SNO

Industry security guidance:

• RHIVOS (Red Hat In-Vehicle OS) conducted a formal kernel filesystem risk assessment and implemented module whitelisting, stating: "an attacker cannot load the unexpected modules into the kernel, and thus exploit security problems in kernel code that is otherwise unused"
• CoreOS tracker #249 discusses kernel module management approaches
• FCOS tracker #2152 — active discussion (May 2026) among FCOS/RHCOS maintainers on denylisting unused kernel modules by default, citing vulnerability exploitation via auto-loading. Fedora already blacklists 10 similar modules
• secureblue runs in production with all five of these modules blacklisted

Customer demand:

• Telco customers (e.g., Bell Mobility) have requested CIS-compliant kernel module controls on OCP, including module loading audit and hardening

Testing

Verified on OCP 4.22 (MNO, 3 master + 2 worker) and OCP 4.21 (SNO) that
blacklisting these 5 modules causes no functional regressions. These modules
are not loaded by default on RHCOS and have no consumers in the container
host stack.

References

• CIS Benchmark RHEL 9 v2.0.0, Section 1.1.1
• Upstream strategy analysis
• CoreOS tracker #249 — module management discussion
• [NIST SP 800-53 CM-7](https://csf.tools/reference/nist-sp-800-53/r5/cm/cm-7/) — Least Functionality

Assisted by: Claude (Anthropic)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sebrandon1
Once this PR has been reviewed and has the lgtm label, please assign tlbueno for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @sebrandon1. Thanks for your PR.

I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sebrandon1]

@jlebon This is a fresh PR replacing #288 (which had broken branch history after a force-push). Same content with your review feedback addressed:

1. Commit message — full context with module list, rationale, exclusions, CIS reference
2. Assisted-by attribution — Assisted-by: Claude (Anthropic) in commit message and PR description
3. UDF removed — dropped from the blacklist per your Azure Ignition finding (ignition/azure.go#L59-L62). Now 5 modules, UDF listed in exclusions.

[travier]

Related to coreos/fedora-coreos-tracker#2152. We should maybe do that upstream first?

[dustymabe]

I think my stance on this is that coreos/rhel-coreos-config is the RHEL layer and openshift/os is the OCP Node layer.

Today we have:

• rhel-bootc -> rhel-coreos-config (bootimages) -> openshift/os (OCP Node Layer)

Over time IMO we should be trying to minimize what's in rhel-coreos-config.

The logic goes like this:

1. If this change makes sense for all of RHEL -> implement in rhel-bootc
2. If this change makes sense only for OCP -> implement in openshift/os

Now, there could be exceptions. For example if RHEL won't accept a change and for some reason implementing it at the openshift/os layer doesn't actually achieve the goal. Then we could implement it at the rhel-coreos-config layer, but I'd prefer to not start there.

---

Related to @travier's comment:

Related to coreos/fedora-coreos-tracker#2152. We should maybe do that upstream first?

I kind of feel the same way upstream as I do downstream (i.e. my comment above) even though things are slightly different. I still argue if we want these "security hardening" features we should implement them in Fedora either for all of Fedora OR for a subset of Fedora where a generalization can be made (like "definitely don't need this kernel module on Server use cases").

[sebrandon1]

Interesting! Good to know the flow/hierarchy of things. I'm willing to try whatever. I can try opening up this PR in openshift/os.

[sebrandon1]

Opened the equivalent PR at the OCP node layer per @dustymabe's guidance: openshift/os#1951

[sebrandon1]

Closing in favor of: openshift/os#1951