-
Spike
-
Resolution: Done
-
Critical
-
None
-
None
-
False
-
-
False
-
-
Impact statement for the OCPBUGS-63680 series:
Which 4.y.z to 4.y'.z' updates increase vulnerability?
Updates to the following affected versions increase the vulnerbility:
- Any updates to 4.16.47 through 4.16.50, fixed in 4.16.51
- Any updates to 4.17.40 through 4.17.42, fixed in 4.17.43
- Any updates to 4.18.24 through 4.18.26, fixed in 4.18.27
Updates between affected releases (e.g. 4.18.24 to 4.18.25) do not increase the exposure.
Which types of clusters?
- Clusters that have third party kernel modules loaded of which we know the following to be problematic, do not consider this to be an exhaustive list
- Oracle [ oracleoks ]
- IBM [ mmfs26 ]
- IBM [ tracedev ]
- HPE [ ice ]
- HPE [ numatools ]
- Portworx [ px ]
- eTrust [ SEOS ]
What is the impact? Is it serious enough to warrant removing update recommendations?
- Nodes will kernel panic and fail to boot, during a normal update this will manifest as Machine Config Pools which fail to make progress once the maxUnavailable value is hit and provided the cluster has spare capacity cluster overall health should not be compromised
How involved is remediation?
- Pause MachineConfigPools to stop additional rollout
- Restore the desiredConfig label on a node to the previous known good rendered MachineConfig prior to the update and boot the previous rpm-ostree state
Is this a regression?
- Yes, introdcued in kernel version kernel-5.14.0-427.95.1.el9_4 and subsequently fixed in kernel-5.14.0-427.96.1.el9_4, the issue was tracked via https://issues.redhat.com/browse/RHEL-120167
- Additional details may be found in https://access.redhat.com/solutions/7131987
- blocks
-
OCPBUGS-63680 OCP node getting rebooted due to kernel panic by loading of third party modules.
-
- Closed
-
- links to