CVEs in Enterprise Linux: How Red Hat and SUSE Handle Security Vulnerabilities

Introduction

In today’s enterprise IT landscape, security is paramount. Organizations running Linux distributions like Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) rely on these platforms for mission-critical workloads. But with the growing complexity of software, vulnerabilities are inevitable. This is where CVEs (Common Vulnerabilities and Exposures) come into play. CVEs provide a standardized way to identify and track security flaws, enabling vendors and customers to respond quickly and effectively. In this blog, we’ll explore what CVEs are, why they matter, and how RHEL and SLES integrate CVE management into their kernel update strategies.

---

1. What is a CVE? [Common Vulnerabilities and Exposures]?

   A CVE is a unique identifier for a publicly known cybersecurity vulnerability.

   Example: CVE-2025-12345

   2025 → Year the CVE was assigned

   12345 → Sequential ID number

1. Why CVEs Matter for Enterprise Linux

   • Compliance and risk management.
   • Security patching and lifecycle.
   • Impact on mission-critical workloads.

2. How Red Hat Handles CVEs

   • RHEL kernel update process.
   • Example: RHEL 9.6 kernel update fixing CVE-2025-38724 (NFSd UAF) and others.
   • Integration with Red Hat Security Advisories (RHSA).

3. How SUSE Handles CVEs

   • SLES kernel update process.
   • Example: SLES 15 SP6 fixing CVE-2025-23145 (MPTCP NULL pointer) and others.
   • SUSE Security Announcements and patching strategy.

4. Enterprise Strategy

   • Why vendors stick to specific kernel versions (stability, certification, compliance).
   • Backporting fixes vs. upgrading kernels.

---

Purpose of CVEs

• Provide a common reference for security professionals, vendors, and customers.
• Helps organizations track, prioritize, and patch vulnerabilities consistently.
• Used by tools like Vulnerability Scanners, Patch Management Systems, and Security Advisories.

---

How CVEs Work

1. A vulnerability is discovered in software (e.g., Linux kernel, OpenSSL).
2. It is reported to a CVE Numbering Authority (CNA) (e.g., Red Hat, SUSE, MITRE).
3. The CNA assigns a CVE ID and publishes details:
   • Description of the vulnerability
   • Severity score (CVSS)
   • Affected versions
   • Fix or mitigation steps

---

Why Important for RHEL and SLES

• Both RHEL and SLES maintain security advisories tied to CVEs.
• Customers rely on CVE tracking for:
  • Compliance (e.g., PCI-DSS, HIPAA)
  • Risk management
  • Patch planning
• Example:
• RHEL 9 kernel update might fix CVE-2024-1234 (privilege escalation bug).
• SLES 15 SP6 update might address CVE-2025-5678 (memory corruption issue).

Here’s how CVEs (Common Vulnerabilities and Exposures) are directly linked to kernel updates in RHEL and SLES, with recent critical examples:

---

 RHEL Kernel Updates and CVEs

Recent Red Hat advisories show kernel updates fixing multiple CVEs. For example:

• RHEL 9.6 (Kernel 5.14.0-570) update fixed:
  • CVE-2025-38724: nfsd – Handle get_client_locked() failure in nfsd4_setclientid_confirm() (Use-After-Free risk)
  • CVE-2025-39864: wifi: cfg80211 – Fix use-after-free in cmp_bss()
  • CVE-2025-39883: mm/memory-failure – Fix VM_BUG_ON_PAGE when unpoison memory
  • CVE-2025-39881: kernfs – Fix UAF in polling when open file is released
  • CVE-2025-39918: wifi: mt76 – Fix linked list corruption
  • CVE-2025-39955: tcp – Clear fastopen_rsk in tcp_disconnect()
  • CVE-2025-40186: tcp – Avoid calling reqsk_fastopen_remove() in tcp_conn_request() 

Older RHEL 8.6 update fixed:

• CVE-2025-21764: ndisc – Use RCU protection in ndisc_alloc_skb() 

---

SLES Kernel Updates and CVEs

SUSE advisories also tie kernel updates to CVEs:

• SLES 15 SP6 (Kernel 6.4.0) update fixed:

  • CVE-2025-23145: mptcp – Fix NULL pointer in can_accept_new_subflow
  • CVE-2025-38500: xfrm – Fix use-after-free after changing collect_md xfrm interface
  • CVE-2025-38616: tls – Handle data disappearing under TLS ULP 

• SLES 15 SP5 (Kernel 5.14.21) update fixed:

  • CVE-2024-36904: tcp – Use refcount_inc_not_zero() in tcp_twsk_unique()
  • CVE-2024-43861: Fix memory leak for non-IP packets
  • CVE-2024-35949: btrfs – Ensure WRITTEN flag on metadata blocks [suse.com]

• SLES 15 SP6 (Kernel 6.4) also addressed:

  • CVE-2024-40956: dmaengine: idxd – Fix possible Use-After-Free in IRQ processing
  • CVE-2024-53104: media: uvcvideo – Skip parsing undefined frame types [linuxsecurity.com]

---

Why This Matters

• Each kernel update bundles fixes for multiple CVEs.
• Customers track CVEs for risk assessment and compliance.
• Vendors provide CVSS scores and patch instructions in advisories.

-------------------------------------------------------------------------------------------------------------------------

From Upstream to Enterprise: Kernel Version in RHEL and SLES

Above diagram showing the relationship between Stable upstream Linux kernel and enterprise distributions across versions:

Latest Stable: 6.18 (Released Nov 30, 2025)

Current Preview: 6.18-rc6 (Mainline development)

LTS Kernels:

• 6.12 (Released Nov 2024, supported until Dec 2036)
• 6.1 (Released Dec 2022, supported until Dec 2027)

NOTE: RHEL 10 and SLES 16 will likely stick to 6.12 LTS for stability and certification, even though 6.18 is the latest mainline.Vendors prefer LTS kernels because they offer long-term maintenance and predictable patching.

Red Hat Enterprise Linux

• RHEL 8 → 4.18. Chosen for stability and maturity during 2019 launch. 
• RHEL 9 → 5.14. Needed for modern hardware enablement and performance improvements.
• RHEL 10 → 6.12.x.  Aligns with upstream LTS and cloud-native workloads.

SUSE Linux Enterprise Server

• SLES 15 SP4 and SP5 → 5.14.x. Matches RHEL 9 for hardware parity.
• SLES 15 SP6 and SP7 → 6.4.x. Early adoption of newer kernel for HPC and AI workloads.
• SLES 16 → 6.12.x.  Future-proof for next-gen enterprise and cloud environments

Note: Enterprise distros generally track LTS lines for stability. RHEL 10 and SLES 16 are on the 6.12 LTS family, even though upstream’s latest stable is 6.18

Why Customers Choose a Particular Kernel Version

1. Stability and Long-Term Support

• Enterprise customers prioritize predictable, stable kernels over bleeding-edge features.
• RHEL and SLES pick a kernel version and backport critical fixes and features rather than upgrading to every new upstream kernel.
• Example: RHEL 8 stayed on 4.18 for years, even though upstream Linux moved to 5.x and 6.x, because 4.18 was proven stable and certified.

2. Hardware Enablement

• New kernels bring support for new CPUs, GPUs, storage, and networking hardware.
• RHEL 9 moved to 5.14 because it enabled next-gen AMD EPYC, Intel Sapphire Rapids, and PCIe Gen5.
• SLES 15 SP6/SP7 jumped to 6.4 for AI/ML accelerators and modern NVMe improvements.

3. Security and Compliance

• Enterprise kernels integrate SELinux/AppArmor, FIPS, and CVE patches.
• Vendors backport security fixes from newer kernels into their chosen LTS kernel.
• This ensures compliance with government and industry standards without breaking stability.

4. Ecosystem and Certification

• ISVs (Independent Software Vendors) and OEMs certify their apps/drivers on specific kernels.
• Customers stick to those versions for SAP, Oracle DB, VMware, and cloud certifications.

5. Performance and Feature Balance

• RHEL 10 and SLES 16 adopt 6.12 because it brings:
  • Improved scalability for large NUMA systems
  • Better BPF and eBPF observability
  • Enhanced container performance

---

______________________________________________________________________________________________

RHEL kernel families:

• RHEL 8.x → Kernel 4.18.x
• RHEL 9.x → Kernel 5.14.x
• RHEL 10.x → Kernel 6.12.x

RHEL 8.x → Kernel Versions (4.18 series)

• RHEL 8.0 → 4.18.0-80
• RHEL 8.1 → 4.18.0-147
• RHEL 8.2 → 4.18.0-193
• RHEL 8.3 → 4.18.0-240
• RHEL 8.4 → 4.18.0-305
• RHEL 8.5 → 4.18.0-348
• RHEL 8.6 → 4.18.0-372
• RHEL 8.7 → 4.18.0-425
• RHEL 8.8 → 4.18.0-477
• RHEL 8.9 → 4.18.0-513
• RHEL 8.10 → 4.18.0-553

The  Linux 5.14 kernel is available in Red Hat Enterprise Linux 9 series. Specifically:

• RHEL 9.0 (released May 17, 2022) introduced kernel 5.14.0-70.
• All subsequent RHEL 9 minor releases (9.1 through 9.7) continue to use the 5.14 kernel with incremental updates:
  • RHEL 9.1 → 5.14.0-162
  • RHEL 9.2 → 5.14.0-284
  • RHEL 9.3 → 5.14.0-362
  • RHEL 9.4 → 5.14.0-427
  • RHEL 9.5 → 5.14.0-503
  • RHEL 9.6 → 5.14.0-570
  • RHEL 9.7 → 5.14.0-611
  • RHEL 9.8 → 5.14.0-636

RHEL 10.x → Kernel Versions (6.12 series)

• RHEL 10.0 → 6.12.0-55
• RHEL 10.1 → 6.12.0-124
  (Future minor releases will continue with 6.12.x updates) 

If you need Linux 5.14, you should use RHEL 9.x  . RHEL 8 uses kernel 4.18, and  RHEL 10 moves to kernel 6.x.

-------------------------------------------------------

SLES kernel families:

• SLES 15 SP4 & SP5 → Kernel 5.14.x
• SLES 15 SP6 & SP7 → Kernel 6.4.x
• SLES 16 → Kernel 6.12.x

SLES 15.x Series

• SLES 15 SP4 → 5.14.21-150400.24.184.1
• SLES 15 SP5 → 5.14.21-150500.55.124.1
• SLES 15 SP6 → 6.4.0-150600.23.78.1
• SLES 15 SP7 → 6.4.0-150700.53.22.1 

SLES 16.x Series

• SLES 16.0 → 6.12.0-160000.5.1 (initial release)
• Later updates in SLES 16 continue with 6.12.x kernel family

=============

In the upstream Linux kernel (maintained at kernel.org), development is organized into several branches, each serving a specific purpose:

1. Mainline (Development)

• Branch: master
• Maintained by Linus Torvalds.
• Contains the latest development code.
• New features and major changes are merged here during the merge window.
• Example: 6.18-rc6 is the current release candidate for the next stable version.

---

2. Stable

• Maintained by Greg Kroah-Hartman and others.
• Each stable branch corresponds to a released kernel version (e.g., linux-6.18.y).
• Only bug fixes and security patches are applied.
• No new features.

---

3. Long-Term Support (LTS)

• Maintained for years (2–6+ years).
• Examples:
  • 6.12 LTS (supported until Dec 2036)
  • 6.1 LTS (supported until Dec 2027)
• Used by enterprise distros like RHEL and SLES for stability.

---

4. Next (linux-next)

• Integration branch for testing patches before they go into mainline.
• Acts as a staging area for subsystem maintainers.

---

5. Architecture/Subsystem Trees

• Maintainers for specific areas (e.g., networking, filesystems, drivers) have their own branches.
• These feed into linux-next, then mainline.

Example :  Mainline → Stable → LTS → Enterprise distros

• Mainline (Development) – features merged here.
• Stable series – short‑term maintenance, e.g. 6.18.
• Long‑Term Support (LTS) – multi‑year maintenance, e.g. 6.12.
• Flow into Enterprise distros:
  • RHEL typically tracks an LTS line (RHEL 10 → 6.12.x).
  • SLES also tracks an LTS line (SLES 16 → 6.12.x).

Conclusion

Security is not optional—it’s a continuous process. CVEs provide a transparent and standardized way to manage vulnerabilities across the Linux ecosystem. Both Red Hat and SUSE have robust mechanisms to track, patch, and communicate CVE fixes, ensuring enterprise customers can maintain compliance and minimize risk without sacrificing stability. Understanding CVEs and their role in kernel updates empowers IT teams to make informed decisions about patching and lifecycle management.