Impact assessment for OCPBUGS-22266.

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

• All updates seem vulnerable (both 4.12 to 4.13 and 4.13 to 4.14 have confirmed reproducers). 4.13.(14 <= z < 19) to 4.14 is especially vulnerable because, as described in OTA-1033, 4.13.(14 <= z < 19) were exposed to OCPBUGS-21721 and the recommended mitigation was deleting the CVO pod. Luckily, 4.13.19 is the floor for supported updates to 4.14, so there should not be supported clusters making updates that suggest deleting the CVO pod at the vulnerable point.

Which types of clusters?

• Clusters where the CVO pod is deleted while it is considering an update but blocked on preconditions.

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

• Information like verified and acceptedRisks on the history entry are incomplete (e.g. verified: false despite a successful signature check, and recommended status of updating from vB to vB is unknown in recommendedRisks instead of discussion of the vA to vB situation). This impact is relevant for all updates, whether minor version or patch version.
• Similarly, implicitly enabled capability calculation may be lost, causing some capabilities to be disabled when they should have been implicitly enabled on update. Only minor version updates will add capabilities, so this impact is not relevant for patch update exposure.

How involved is remediation?

• Accidentally disabled capabilities can be implicitly enabled, but there will be a time when those were running their vA code when they should have been updated to their vB code, and therre may be version-skew issues until the capabilities are manually enabled as a result.

Is this a regression?

• reasoning: Certainly not a recent one, with 4.12 CVOs exposed. The current CVO logic is largely unchanged since 4.11's work to separate payload loading from manifest application.