|
| 1 | +//module included in cluster-logging-release-notes.adoc |
| 2 | +:_content-type: REFERENCE |
| 3 | +[id="cluster-logging-release-notes-5-5-4_{context}"] |
| 4 | += Logging 5.5.4 |
| 5 | +This release includes link:https://access.redhat.com/errata/RHSA-2022:7434[RHSA-2022:7434-OpenShift Logging Bug Fix Release 5.5.4]. |
| 6 | + |
| 7 | +[id="openshift-logging-5-5-4-bug-fixes"] |
| 8 | +== Bug fixes |
| 9 | +* Before this update, an error in the query parser of the logging view plugin caused parts of the logs query to disappear if the query contained curly brackets `{}`. This made the queries invalid, leading to errors being returned for valid queries. With this update, the parser correctly handles these queries. (link:https://issues.redhat.com/browse/LOG-3042[LOG-3042]) |
| 10 | + |
| 11 | +* Before this update, the Operator could enter a loop of removing and recreating the collector daemonset while the Elasticsearch or Kibana deployments changed their status. With this update, a fix in the status handling of the Operator resolves the issue. (link:https://issues.redhat.com/browse/LOG-3049[LOG-3049]) |
| 12 | + |
| 13 | +* Before this update, no alerts were implemented to support the collector implementation of Vector. This change adds Vector alerts and deploys separate alerts, depending upon the chosen collector implementation. (link:https://issues.redhat.com/browse/LOG-3127[LOG-3127]) |
| 14 | + |
| 15 | +* Before this update, the secret creation component of the Elasticsearch Operator modified internal secrets constantly. With this update, the existing secret is properly handled. (link:https://issues.redhat.com/browse/LOG-3138[LOG-3138]) |
| 16 | + |
| 17 | +* Before this update, a prior refactoring of the logging `must-gather` scripts removed the expected location for the artifacts. This update reverts that change to write artifacts to the `/must-gather` folder. (link:https://issues.redhat.com/browse/LOG-3213[LOG-3213]) |
| 18 | + |
| 19 | +* Before this update, on certain clusters, the Prometheus exporter would bind on IPv4 instead of IPv6. After this update, Fluentd detects the IP version and binds to `0.0.0.0` for IPv4 or `[::]` for IPv6. (link:https://issues.redhat.com/browse/LOG-3162[LOG-3162]) |
| 20 | + |
| 21 | +[id="openshift-logging-5-5-4-CVEs"] |
| 22 | +== CVEs |
| 23 | +* link:https://access.redhat.com/security/cve/CVE-2020-35525[CVE-2020-35525] |
| 24 | +* link:https://access.redhat.com/security/cve/CVE-2020-35527[CVE-2020-35527] |
| 25 | +* link:https://access.redhat.com/security/cve/CVE-2022-0494[CVE-2022-0494] |
| 26 | +* link:https://access.redhat.com/security/cve/CVE-2022-1353[CVE-2022-1353] |
| 27 | +* link:https://access.redhat.com/security/cve/CVE-2022-2509[CVE-2022-2509] |
| 28 | +* link:https://access.redhat.com/security/cve/CVE-2022-2588[CVE-2022-2588] |
| 29 | +* link:https://access.redhat.com/security/cve/CVE-2022-3515[CVE-2022-3515] |
| 30 | +* link:https://access.redhat.com/security/cve/CVE-2022-21618[CVE-2022-21618] |
| 31 | +* link:https://access.redhat.com/security/cve/CVE-2022-21619[CVE-2022-21619] |
| 32 | +* link:https://access.redhat.com/security/cve/CVE-2022-21624[CVE-2022-21624] |
| 33 | +* link:https://access.redhat.com/security/cve/CVE-2022-21626[CVE-2022-21626] |
| 34 | +* link:https://access.redhat.com/security/cve/CVE-2022-21628[CVE-2022-21628] |
| 35 | +* link:https://access.redhat.com/security/cve/CVE-2022-23816[CVE-2022-23816] |
| 36 | +* link:https://access.redhat.com/security/cve/CVE-2022-23825[CVE-2022-23825] |
| 37 | +* link:https://access.redhat.com/security/cve/CVE-2022-29900[CVE-2022-29900] |
| 38 | +* link:https://access.redhat.com/security/cve/CVE-2022-29901[CVE-2022-29901] |
| 39 | +* link:https://access.redhat.com/security/cve/CVE-2022-32149[CVE-2022-32149] |
| 40 | +* link:https://access.redhat.com/security/cve/CVE-2022-37434[CVE-2022-37434] |
| 41 | +* link:https://access.redhat.com/security/cve/CVE-2022-40674[CVE-2022-40674] |
0 commit comments