Recovering from clusters that automatically updated to v4.18 kernel-module-management despite running older OCP

Solution Verified - Updated

Environment

  • Red Hat OpenShift Container Platform (RHOCP)
    • < 4.18
  • KMM Operator

Issue

For several hours on February 3, 2026, Red Hat released 4.18 Red Hat Operators catalog content into 4.12-4.17 clusters. The tags have since been recovered to point at catalogs appropriate for their 4.y. Clusters running 4.12 through 4.17 versions during the window from 2026-02-03 21:16 UTC through 2026-02-04 05:18 UTC were impacted by the 4.18 catalog content.

Specifically, the operators with installPlanApproval:Automatic on Subscription.operators.coreos.com which had updates recommended in the 4.18 catalog had their installed operator version updated to the version present in the 4.18 catalog, regardless of whether that version was appropriate for the version of OCP that the cluster was running.

Due to the above, clusters could have the kernel-module-management (KMM) operator upgraded to latest new version supported by OCP 4.18.

Resolution

In general, KMM is not dependent on the OCP version and is designed to be backward compatible. That means that newer KMM version can be executed on the older OCP version.

We recommend not downgrading the KMM version since the newer version provides additional bug fixes and features, and can be successfully deployed on the older OCP version.

In case the user requires downgrading of KMM to the previous version, follow the following procedure. Be aware that the downgrade can result in a temporary workload disruption as kernel modules are unloaded and reloaded into the kernel.

There are 2 ways to that KMM is usually used, by a user manually deploying KMM module, or by another operator creating KMM Module via its code:

Note: In either scenario it is highly recommended to not downgrade the KMM, but to continue using the new version

Downgrading if the user manually deployed KMM Module:

  1. Identify the workloads that are using kernel module(s) deployed by KMM.

  2. If any such workloads exist - delete them

  3. Use the operator's CR to delete the KMM Module

  4. Uninstall KMM Operator

  5. Install KMM Operator from the appropriate catalog

  6. Reinstall KMM Module and use "oc" utility to install the save KMM Module from the previously saved yaml file

  7. Re-institute the workloads deleted in step 2.

Downgrading if KMM was installed as a dependency for another operator:

  1. Identify the workloads that are using kernel module(s) deployed by KMM.

  2. If any such workloads exist - delete them

  3. Save the current KMM module to a file using "oc" utility, and then remove KMM Module from the cluster

  4. Uninstall KMM Operator

  5. Install KMM Operator from the appropriate catalog

  6. Re-create the parent operator's CR, which will lead to creation of the KMM Module

  7. Re-institute the workloads deleted in step 2.

Diagnostic Steps

  • KMM 2.5.1 is running on OCP 4.13

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.