What is backporting and how does it affect Red Hat Enterprise Linux (RHEL)?

Solution Verified - Updated -


  • Red Hat Enterprise Linux (RHEL)
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9


  • What is backporting and how does it affect Red Hat Enterprise Linux (RHEL)?
  • The recommended RHEL package version for a CVE does not match the upstream package version.
  • Why are RHEL package versions behind the upstream versions?


Backporting security fixes
  • Red Hat use the term backporting to describe when it takes a fix for a security flaw out of the most recent version of an upstream software package, and applies that fix to an older version of the package distributed by Red Hat.

  • Backporting will be a new concept for those more familiar with proprietary software updates. Here is an example of why Red Hat backport security fixes:

  • Red Hat shipped version 2.0.40 of the Apache HTTP Server with Red Hat Linux 8.0. Shortly after the release, a number of security issues were found and disclosed by the Apache Software Foundation. The Apache Software Foundation issued a new release, Apache HTTP Server 2.0.43, which contained fixes for those issues; however, in addition to the security fixes, a number of other changes (bug fixes and new features) were made between versions 2.0.40 and 2.0.43.

  • One of these features changed the module interface. In this case, if Red Hat issued a security update with version 2.0.43 of the Apache HTTP Server, replacing version 2.0.40, any modules which were in use would need be updated (recompiled) to match the new module interface. If third-party modules are being used, needs to go to the supplier of those modules to get updates. Moving from version 2.0.40 to 2.0.43 of the Apache HTTP Server would require manual effort by system administrators. Such an update would not be suitable for automated upgrade systems such as the Red Hat Network.

  • In cases like these Red Hat can backport the updates. When Red Hat backport security fixes Red Hat:

    • identify the fixes and isolate them from any other changes.
    • make sure the fixes do not introduce unwanted side effects.
    • apply the fixes to previously released versions.
  • For most products the default practice is to backport security fixes, but Red Hat do sometimes provide version updates for some packages after careful testing and analysis. These are likely to be packages that have no interaction with others, or those used by an end-user, such as web browsers and instant messaging clients.

Explaining common release numbering confusion
  • Backporting has a number of advantages, but it can create confusion when it is not understood.  For example, stories in the press may include phrases such as "upgrade to Apache httpd 2.0.43 to fix the issue", which only takes into account the upstream version number. This can cause confusion as even after installing updated packages from a vendor, it is not likely to have the latest upstream version, but rather have an older upstream version with backported patches applied.

  • Also, some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes.

  • Security issues flagged by Nessus reveals false positives

  • Since the introduction of Red Hat Enterprise Linux, Red Hat has been careful to explain in it's security advisories how it fixed an issue: by moving to a new upstream version, or by backporting patches to the existing version. Red Hat has attached CVE names to all it's advisories since January 2000, allowing all to easily cross-reference vulnerabilities and find out how and when Red Hat fixed them, independent of version numbers.

  • Red Hat also supply OVAL definitions (machine-readable versions of advisories) that third-party vulnerability tools can use to determine the status of vulnerabilities, even when security fixes have been backported.

  • For latest updates refer to: Backporting Security Fixes

  • After an upstream project has released a newer version of a package when will the package on a Red Hat Enterprise Linux System be updated to this version?

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


Urgent: The DMZ Prod EDMZ and DR EDMZ server need to patched for vulnerability found by security scan. Details attached.
Order Description
The security scan group has found vulnerabilities on the MHE EDMZ Production and DR servers as part of the First Quarter External Scan Results and an Immediate Action is Required. The HRIT Prod EDMZ Server ew1ctgl5745-mgt.emhe.mhc and HRIT DR EDMZ Server sc1gtgu5288-mgt.emhe.mhc need to fixed for the volunerabilities identified by the security team.
Please see attached email and security vulnerabilities documents.

Server OS Current Version is RHEL 5.6 and SSH is openssh-4.3p2-72.el5 .

kindly suggest in resolving issue.

Could you please make this article public accessible? Some of our customers have a bad time understanding how "backporting" works. Giving them this link would help us a lot!

Should be quite helpful if you explained if back-ported patches were placed in the standard repo, or if one required a new repo assigned to a server.

Backported patches go into all Red Hat products. So every time you yum update and there is something new, you're getting a package with new backports in it.

If backported patches go to all Red Hat products (assuming this implies standard repositories and Extended Update Support repositories), then what is the purpose for EUS add-on? Why would customer buy it (in addition to standard subscription)?

You'd use EUS to keep a longer lifecycle on a previous minor release. The default backport is only to the current minor release.

So for example, you might have an environment on RHEL 8.2 or 8.4 (EUS releases). An issue today would be fixed in future RHEL 8.6 and might be backported to 8.5 as well. If you wanted to request fix in the EUS releases 8.2 or 8.4, that's what EUS adds.

As far as I know, EUS is now included in many Premium subscriptions. I am not exactly sure what each of the products provides, Customer Service or Sales are happy to offer advice there.

Link in "Red Hat also supply 'OVAL definitions' (machine-readable versions of advisories) that third-party vulnerability tools can use to determine the status of vulnerabilities, even when security fixes have been backported." does not seem to be valid.

We need to point people to this article who do not otherwise have logins at https://access.redhat.com. Can we shift this to a publicly available location?

I removed the restriction, now non-subscribers can read this full solution and comments without a login.