Red Hat Errata help users determine what updates are available and how important they are based on analysis by Red Hat engineering. These updates can address security issues, fix bugs, or provide new features for individual packages and entire container images. Errata are published for low level, operating system packages like the kernel and glibc, as well as layered products which are delivered as packages.
This article explains what Red Hat Errata are, why Red Hat produces them, how users can consume them, the difference between major types (RHSA, RHBA, and RHEA), and the numbering and naming of advisories.
What is Errata
The word errata comes from Latin and is the plural form of the word erratum. Historically, the word erratum referred to a correction of a published text, typically because of an error in the publishing process. Red Hat Errata refers to the correction or update of a software package based on a security issue, bug, or the availability of a new feature. Note, Red Hat uses the terms errata, advisory, and even errata advisory interchangeably. The advisory (errata advisory) is the published text; the errata is the packaged release.
Advisories can help users track which Common Vulnerabilities and Exposures (CVE) are resolved, which bugs have been addressed, and which features have been added. To get an idea of what information errata provide, inspect the following command. Notice that the output provides the errata ID, type , security impact or severity rating (see: https://access.redhat.com/security/updates/classification if security related), classification, and the package(s)/version(s) for which this errata is applicable.
RHEL 8 example command:
yum updateinfo --list
RHEL 7 example command:
yum updateinfo list
RHEL 7 truncated output:
Loaded plugins: product-id, search-disabled-repos, subscription-manage ... RHSA-2019:2197 Low/Sec. elfutils-libs-0.176-2.el7.x86_64 RHEA-2019:2214 enhancement ethtool-2:4.8-10.el7.x86_64 RHBA-2019:2024 bugfix firewalld-0.6.3-2.el7.noarch ...
Advisories are pieces of metadata that tie an update to a human-readable description. These advisories are created by Red Hat engineering when they generate a new package and are published on the Red Hat Customer Portal. Advisories come in three types:
- Red Hat Security Advisory (RHSA) : RHSAs contain one or more security fixes and might also contain bug or enhancements fixes. RHSAs are generally considered the most important type of errata for many organizations. RHSAs are ranked using a severity rating of Low, Moderate, Important, or Critical based on the severity of the vulnerability.
- Red Hat Bug Advisory (RHBA): RHBAs always contain one or more bug fixes and might contain enhancements, but do not contain security fixes. Because RHBAs are released for bug fixes, they are often considered more important than an RHEA in priority.
- Red Hat Enhancement Advisory (RHEA): RHEAs contain one or more enhancements or new features and do not contain bug fixes or security fixes. Essentially, a RHEA is released when new features are added and an updated package is shipped.
Red Hat commits to generating errata advisories for different products based on public lifecycle policies. Below are some examples:
To explain how to use Errata, let’s start with some example scenarios.
Determining whether any security updates are available for a package
For the first example, let’s say you have a RHEL server. Because glibc is a core library used by almost every binary on the system, you want to verify whether there are any security updates available.
First, let’s see what version of glibc is installed:
rpm -qa | grep glibc
Example RHEL 7 output:
Now, let’s see what version is available and if it updates anything important:
yum updateinfo list | grep glibc
Example RHEL 7 output:
RHSA-2019:2118 Moderate/Sec. glibc-2.17-292.el7.x86_64 RHSA-2019:2118 Moderate/Sec. glibc-common-2.17-292.el7.x86_64
Notice that there is a moderate RHSA which is updated by moving from the currently installed version (2.17-260) to the available version (2.17-292). Based on this information, it might be prudent to update to the latest version:
yum update -y glibc
Example truncated output:
... Updated: glibc.x86_64 0:2.17-292.el7 Dependency Updated: glibc-common.x86_64 0:2.17-292.el7
Using Red Hat published Errata advisories connected to packages, we can be confident that we have resolved the vulnerability.
Determining whether any security updates are available for a container
Let’s say you are working with Red Hat Universal Base image(UBI) on a supported RHEL container host and you want to verify whether any errata is available. Example Command (RHEL 7 or 8):
podman run -it ubi8 yum updateinfo --list
Updating Subscription Management repositories. Unable to read consumer identity Subscription Manager is operating in container mode. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 2.9 MB/s | 9.2 MB 00:03 Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 4.0 MB/s | 8.1 MB 00:02 Red Hat Universal Base Image 8 (RPMs) - AppStream 1.1 MB/s | 1.9 MB 00:01 Red Hat Universal Base Image 8 (RPMs) - BaseOS 1.4 MB/s | 754 kB 00:00 Last metadata expiration check: 0:00:01 ago on Fri Aug 2 04:38:54 2019. RHBA-2019:2707 bugfix bash-4.4.19-8.el8_0.x86_64 RHSA-2019:2692 Important/Sec. libnghttp2-1.33.0-1.el8_0.1.x86_64 RHBA-2019:1957 bugfix platform-python-3.6.8-4.el8_0.x86_64 RHBA-2019:1957 bugfix python3-libs-3.6.8-4.el8_0.x86_64 RHBA-2019:1958 bugfix python3-rpm-4.14.2-10.el8_0.x86_64 RHBA-2019:2709 bugfix python3-rpm-4.14.2-11.el8_0.x86_64 RHBA-2019:1958 bugfix rpm-4.14.2-10.el8_0.x86_64 RHBA-2019:2709 bugfix rpm-4.14.2-11.el8_0.x86_64 RHBA-2019:1958 bugfix rpm-build-libs-4.14.2-10.el8_0.x86_64 RHBA-2019:2709 bugfix rpm-build-libs-4.14.2-11.el8_0.x86_64 RHBA-2019:1958 bugfix rpm-libs-4.14.2-10.el8_0.x86_64 RHBA-2019:2709 bugfix rpm-libs-4.14.2-11.el8_0.x86_64 RHBA-2019:1703 bugfix tzdata-2019b-1.el8.noarch RHBA-2019:2871 bugfix tzdata-2019c-1.el8.noarch
Notice that when UBI is run on a subscribed Red Hat Enterprise Linux host (7 or 8), it pulls errata information from the RHEL channels (not available in redistributable UBI channels) and displays errata information. This is quite useful in verifying whether security updates have been applied, especially when security teams request this information.
What happens if an RHEA or RHBA is found to have fixed a security flaw?
Sometimes, due to code rebases or software changes later being found to have a security impact, an RHEA or RHBA also addresses a security flaw. For example, CVE-2015-5201 updated packages for the rhev-hypervisor package (essentially a stripped-down Red Hat Enterprise Linux system image designed to provide a host for virtual machines) which was already included in RHEA-2015:2527. The CVE was, therefore, retroactively added to the RHEA advisory (as can be seen on its web page). However, to avoid confusion, because the type of advisory (RHEA, RHBA, or RHSA) is part of the URL, the advisory itself was not relabelled as an RHSA.
How does advisory numbering work?
All advisories are given a year and a sequential number, which starts at 0001 and ends at the number of advisories shipped for that year. The first advisory might be an RHBA, the second an RHEA, and the third an RHSA, and all are given numbers in the same sequence. This explains why RHSA numbers often skip ahead; the intervening numbers are simply used for RHBA and RHEA advisories. Also note that although most advisory numbers are typically assigned shortly before the advisory is released, some are assigned in advance, so when you look at advisories in chronological order, they might not be in numerical order.