Explaining Red Hat Errata (RHSA, RHBA, and RHEA)

Updated -

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:

Red Hat Enterprise Linux Life Cycle
Red Hat Universal Base Image - Content Availability

Using Errata

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:

  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

Example output:

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.

Accessing Errata

In addition to the command line examples above, users can access Red Hat published errata and advisories in several ways:
Red Hat Customer Portal
Satellite Server

Additional information
CVE Database
Security Labs

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.

Notifications and Advisories

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.


Yum updateinfo showing below output on RHEL 7.7

CL-BA-2019:2601 bugfix   NetworkManager-1:1.18.0-5.el7_7.1.x86_64

Why it is not showing as RHBA-2019:2601 ?

Question... When running the command below and being notified that there is a bugfix, does that check the currently pulled down updates in the content-view? Or is that checking with RedHat to say there is something available to pull down...

The reason I ask, you can see below it says there is nothing to do... Am I missing something?

dnf updateinfo

Updating Subscription Management repositories.

Red Hat Enterprise Linux 8 for x86_64 - Supplementary (RPMs) 41 kB/s | 2.1 kB 00:00

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 44 kB/s | 2.4 kB 00:00

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 52 kB/s | 2.8 kB 00:00

Updates Information Summary: available

1 Bugfix notice(s)
dnf --bugfix update

Updating Subscription Management repositories.

Red Hat Enterprise Linux 8 for x86_64 - Supplementary (RPMs) 40 kB/s | 2.1 kB 00:00

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 45 kB/s | 2.4 kB 00:00

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 54 kB/s | 2.8 kB 00:00

No security updates needed, but 0 updates available

Dependencies resolved.

Nothing to do. Complete!

Hey William, I was wondering if you did find an answer for this?

Sorry for the late reply... I didn't get a notification of your question.... But I never did get an answer

In case there is a security vulnerability in glibc that affects RHEL 7 as well as RHEL 8. Would the advisory number be the same for both of them? Or would there be two different advisory numbers, one for RHEL 7 and one for RHEL 8?


Sometimes one RHSA can ship fixes for multiple products, other times they are separated across multiple RHSAs:

Is there some subtle difference between 'errata' and a 'software patch'? I'm familiar enough with errata used in printed media, why call an updated program or package the same thing?

I just stumbled across your question, Rob. To my unlearned understanding, the historical use of "patch" was the act of applying updated code over a section of the currently in-memory running code.  Wikipedia's Binary patches section of the Patch (computing) article describe my understanding of it.

With errata, a new RPM actually replaces the old RPM in the system.  For example, tzdata-2022e-1.el9_0.noarch.rpm released 2022-10-20 in RHBA-2022:7067 replaces tzdata-2022d-1.el9_0.noarch.rpm from 2022-10-06's RHBA-2022:6827  The files from the old RPM are removed from storage and then the files from the new RPM are put on the storage.  No change -- partial or whole -- is made to the code in memory.  (That's why applying the errata is sometimes not enough; one has to restart the running application/service [or maybe even reboot the operating system] for the new code to take effect.)

Although "patching" is like sewing a square patch of cloth over a hole in some pants and errata is like getting a new pair of pants (same brand, color & size), I do hear people erroneously interchange the terms.

I'm sorry, but in industry terms "software patching" has in recent decades meant a partial or full replacement of components to fix e.g. an urgent problem - it's been a long time since patching has automatically meant patching a running program in memory or binary editing an executable or library. Often patches are produced rapidly to fix a problem and then an updated package released later. Sometimes the patch is the updated package, sometimes its a single executable, library or supporting file.

Redhat's use of the term errata is confusing and ill judged - they even allude to it in their text at the top of the page:

"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"

The word "errata" should not be used where you might be talking about introducing a new feature. Bug yes, fixing a security feature that isn't a bug "maybe", certainly not "new features". Language is important - there's no need to confuse.