The impact is a result of the issue tracked in OCPBUGS-15282 and its backports.

Which 4.y.z to 4.y'.z' updates increase vulnerability?

• Any upgrades to 4.12.18 or later, or any 4.13.

Which types of clusters?

• Any cluster with multi network enabled (default) and, with additional networks of type raw and IPAM type whereabouts. You can check with network_attachment_definition_instances > 0 ; any cluster where that returns a time-series is likely exposed, and clusters where the metric is always zero are not exposed.

What is the impact? Is it serious enough to warrant removing update recommendations?

• Updates will stick waiting for the network ClusterOperator to increment its status.versions, which will not happen. Other cluster functionality is not impacted.

How involved is remediation?

Potentially involves setting and leaving the cluster network operator to unmanaged and setting and annotation on whereabouts-reconciler:

oc patch network.operator.openshift.io cluster --patch '{"spec": {"managementState": "Unmanaged"}}'
oc -n openshift-multus annotate daemonset whereabouts-reconciler release.openshift.io/version=4.12.21

The workaround has not been verified or confirmed as working yet.

No procedure yet for the +1 upgrade after this remediation.

Another option for avoiding this is to disable the whereabouts IPAM CNI reconciler by using the following procedure. This will avoid having the reconciler launch and then you don't have to set the state to unmanaged, as an option.

Using this remediation procedure in https://gist.github.com/dougbtv/015ce004967421019cbabe6df60217a2 from SDN-3996

Is this a regression?

• Yes