In x/text in Go 1.15.4, a "slice bounds out of range" panic occurs in language.ParseAcceptLanguage while processing a BCP 47 tag. x/text/language is supposed to be able to parse an HTTP Accept-Language header. Upstream issue: https://github.com/golang/go/issues/42536
Created golang tracking bugs for this issue: Affects: epel-7 [bug 1913365] Affects: fedora-all [bug 1913364]
Upstream patch: https://github.com/golang/text/commit/4482a914f52311356f6f4b7a695d4075ca22c0c6
Removed services which do not appear to use go{lang}, marked remaining services unaffected as specified version not found.
changing score to match worst case scenario, with NVD's score chosen. This could lead to a DOS of anything running on golang, though not our underlying system.
Running deplist[0] on all OCP4 source repos (for the latest current release) gives us the following: cluster-logging-operator-container: golang.org/x/text/language v0.3.2 cluster-node-tuning-operator-container: golang.org/x/text/language v0.3.3 csi-driver-manila-container: golang.org/x/text/language v0.3.2 csi-driver-nfs-container: golang.org/x/text/language v0.3.1-0.20181227161524-e6919f6577db elasticsearch-operator-container: golang.org/x/text/language v0.3.2 local-storage-diskmaker-container: golang.org/x/text/language v0.3.3 local-storage-operator-container: golang.org/x/text/language v0.3.3 multus-cni-container: golang.org/x/text/language v0.3.3 node-feature-discovery-container: golang.org/x/text/language v0.3.3 openshift-enterprise-ansible-operator-container: golang.org/x/text/language v0.3.3 openshift-enterprise-helm-operator-container: golang.org/x/text/language v0.3.3 openshift-enterprise-hyperkube-container: golang.org/x/text/language v0.3.3 openshift-enterprise-tests-container: golang.org/x/text/language v0.3.3 ose-aws-ebs-csi-driver-container: golang.org/x/text/language v0.3.2 ose-baremetal-installer-container: golang.org/x/text/language v0.3.3 ose-elasticsearch-proxy-container: golang.org/x/text/language v0.3.2 ose-installer-artifacts-container: golang.org/x/text/language v0.3.3 ose-installer-container: golang.org/x/text/language v0.3.3 ose-network-metrics-daemon-container: golang.org/x/text/language v0.3.3 ose-ptp-operator-container: golang.org/x/text/language v0.3.3 sriov-network-config-daemon-container: golang.org/x/text/language v0.3.3 sriov-network-must-gather-container: golang.org/x/text/language v0.3.3 sriov-network-operator-container: golang.org/x/text/language v0.3.3 sriov-network-webhook-container: golang.org/x/text/language v0.3.3 cri-o: golang.org/x/text/language v0.3.3 cri-tools: golang.org/x/text/language v0.3.3 openshift: golang.org/x/text/language v0.3.3 podman: golang.org/x/text/language v0.3.2 [0] https://github.com/mcoops/deplist
For OCP 3.11, we need to use `go list -deps ./...` instead of deplist[0] , because deplist doesn't support glide. We lose version numbers with `go list`, however our results are: atomic-enterprise-service-catalog: golang.org/x/text/language atomic-openshift-descheduler: golang.org/x/text/language atomic-openshift-dockerregistry: golang.org/x/text/language atomic-openshift: golang.org/x/text/language atomic-openshift-metrics-server: golang.org/x/text/language atomic-openshift-node-problem-detector: golang.org/x/text/language atomic-openshift-service-idler: golang.org/x/text/language atomic-openshift-web-console: golang.org/x/text/language csi-attacher: golang.org/x/text/language csi-driver-registrar: golang.org/x/text/language csi-livenessprobe: golang.org/x/text/language csi-provisioner: golang.org/x/text/language golang-github-openshift-oauth-proxy: golang.org/x/text/language golang-github-prometheus-prometheus: golang.org/x/text/language heapster: golang.org/x/text/language openshift-enterprise-cluster-capacity: golang.org/x/text/language openshift-enterprise-image-registry: golang.org/x/text/language openshift-external-storage: golang.org/x/text/language podman: golang.org/x/text/language [0] https://github.com/mcoops/deplist
It can be shown with callgraph[0] which main packages use the affected code. A negative example with the operator-registry container[1]: Identify main packages: $ grep -rl --exclude-dir=vendor 'package main' . | grep -E '\.go$' | grep -v 'test' | grep -v 'hack' | xargs dirname 2>/dev/null | sort -u ./cmd/appregistry-server ./cmd/configmap-server ./cmd/initializer ./cmd/opm ./cmd/registry-server Then iterate over these with `callgraph` and grep for any uses of the affected package: $ callgraph -format digraph ./cmd/appregistry-server | grep golang.org/x/text/language $ No results, so this package is not used by the "./cmd/appregistry-server" main package in the operator registry container. A positive example with the installer container[2]: $ callgraph -format digraph ./cmd/openshift-install | golang.org/x/text/language "(*golang.org/x/text/language.Tag).tag" "(golang.org/x/text/internal/language/compact.Tag).Tag" "(golang.org/x/text/language.Tag).MarshalText" "(*golang.org/x/text/language.Tag).tag" "(golang.org/x/text/language.Tag).MarshalText" "(golang.org/x/text/internal/language.Tag).MarshalText" ... We can see that there are functions from the affected package used by "cmd/openshift-install". Therefore we can consider the openshift installer container affected by this CVE. The was repeated for all OpenShift source code repositories. [0] https://github.com/golang/tools/blob/master/cmd/callgraph/main.go [1] https://github.com/operator-framework/operator-registry [2] https://github.com/openshift/installer
In reply to comment #19: > It can be shown with callgraph[0] which main packages use the affected code. > A negative example with the operator-registry container[1]: > > Identify main packages: > > $ grep -rl --exclude-dir=vendor 'package main' . | grep -E '\.go$' | grep -v > 'test' | grep -v 'hack' | xargs dirname 2>/dev/null | sort -u > ./cmd/appregistry-server > ./cmd/configmap-server > ./cmd/initializer > ./cmd/opm > ./cmd/registry-server > > Then iterate over these with `callgraph` and grep for any uses of the > affected package: `go list -deps` can also be used instead of `callgraph`. Using `go list -deps`, we get the same list of OpenShift components. We can go further and say that the affected code is not only unused, it is not imported at all, and therefore not built into the binaries.
Statement: Below Red Hat products include the affected version of 'golang.org/x/text', however the language package is not being used and hence they are rated as having a security impact of Low. A future update may address this issue. * Red Hat OpenShift Container Storage 4 * OpenShift ServiceMesh (OSSM) * Red Hat Gluster Storage 3 * Windows Container Support for Red Hat OpenShift Only three components in OpenShift Container Platform include the affected package, 'golang.org/x/text/language' , the installer, baremetal installer and thanos container images. All other components that include a version of 'golang.org/x/text' do not include the 'language' package and are therefore not affected.
This issue has been addressed in the following products: Red Hat Advanced Cluster Management for Kubernetes 2.2 for RHEL 8 Red Hat Advanced Cluster Management for Kubernetes 2.2 for RHEL 7 Via RHSA-2021:1168 https://access.redhat.com/errata/RHSA-2021:1168
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-28852
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.8 Via RHSA-2021:2438 https://access.redhat.com/errata/RHSA-2021:2438
This issue has been addressed in the following products: Red Hat Advanced Cluster Management for Kubernetes 2.3 for RHEL 7 Red Hat Advanced Cluster Management for Kubernetes 2.3 for RHEL 8 Via RHSA-2021:3016 https://access.redhat.com/errata/RHSA-2021:3016
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.10 Via RHSA-2022:0577 https://access.redhat.com/errata/RHSA-2022:0577
This issue has been addressed in the following products: OpenShift Service Mesh 2.0 Via RHSA-2022:1276 https://access.redhat.com/errata/RHSA-2022:1276
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:7129 https://access.redhat.com/errata/RHSA-2022:7129
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:7954 https://access.redhat.com/errata/RHSA-2022:7954