CVE-2026-81665
Description
A heap-based buffer overflow was found in Corosync's Totem Process Group (totempg) message reassembly. When processing fragmented multicast messages, the buffer used to reassemble fragments lacks a runtime bounds check in release builds. A network-adjacent attacker able to send crafted multicast protocol messages to the cluster could cause a heap buffer overflow with attacker-controlled data. This can crash the Corosync daemon, causing a denial of service to the entire cluster, and may potentially allow further exploitation given sufficient heap-corruption control.
Statement
This vulnerability is rated as Important. The published Red Hat CVSS score is 7.5 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), matching the unmitigated upstream baseline.
RHEL High Availability Add-On clusters are configured via the pcs (Pacemaker/Corosync configuration system) tool, whose 'pcs cluster setup' command has defaulted to generating a corosync.conf with crypto_hash=sha256 and crypto_cipher=aes256 for multiple RHEL 8.x and 9.x releases, which meaningfully reduces real-world risk by requiring an attacker to already possess the cluster's shared authentication key before the vulnerable code is ever reached. This has been confirmed directly with upstream corosync maintainer Jan Friesse (2026-08-31). However, Jan also confirmed that for RHEL <=10 this protection is a configurable default rather than an enforced, non-optional control: an administrator can disable it via the officially supported 'pcs' interface itself (setting cipher=none, hash=none), not only via unsupported manual editing of corosync.conf. Because encryption can be turned off through a supported configuration path, Red Hat is publishing the CVSS score for the worst-case supported configuration (encryption disabled) rather than crediting the default as a permanent mitigating factor.
Administrators who have not explicitly disabled cluster message authentication benefit from a substantially reduced practical risk, equivalent to CVSS 6.4 (CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H), since the knet transport rejects unauthenticated packets before they reach the vulnerable reassembly code. See the Mitigation section for guidance on confirming and enforcing this configuration.
Corosync is shipped in Red Hat Enterprise Linux 7 through 10 and RHIVOS as part of the High Availability Add-On. Firewalld's high-availability service definition (covering the affected knet ports) is not enabled by default, providing additional network-layer defense in depth on systems where firewalld is active. SELinux, enforcing by default on RHEL, confines the corosync_t domain's file writes to corosync-specific paths and restricts network access to UDP only, limiting post-exploitation options, though the domain retains capabilities broad enough that this is not treated as a complete mitigation for CVSS scoring purposes.
Note: upstream corosync HEAD and current Fedora (which will become RHEL 11) now enforce encryption at compile time, removing the ability to disable it entirely without recompiling from source. Once this reaches RHEL as a supported release, this compensating control will become a true enforced guarantee rather than a configurable default, and the published score is expected to be revisited at that time.
Mitigation
There is no complete mitigation for this vulnerability short of a fix, but the following steps significantly reduce risk:
1. Ensure cluster message authentication is enabled in corosync.conf: set crypto_cipher to aes256 and crypto_hash to sha256 (or stronger) in the totem {} block, with a shared key generated by corosync-keygen. This is the default when clusters are configured via 'pcs cluster setup', and disabling it (cipher=none/hash=none) is an explicitly unsupported configuration per upstream maintainer guidance.
2. Restrict network access to the cluster communication ports (default 5405-5412/UDP) to trusted cluster node addresses only, using firewalld or other firewall rules.
3. Ensure SELinux is running in enforcing mode on cluster nodes to limit the impact of any successful exploitation.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | N/A | 7.5 |
| Attack Vector | Adjacent Network | N/A | Adjacent Network |
| Attack Complexity | High | N/A | High |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | High | N/A | High |
Vector
Red Hat: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
cve.org: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Red Hat CVSS v3 Score Explanation
Published at the unmitigated baseline (matching upstream). RHEL HA clusters configured via 'pcs cluster setup' default to cluster message authentication enabled (crypto_hash=sha256, crypto_cipher=aes256), which reduces real-world risk to an equivalent of 6.4 (PR:H) for administrators who have not disabled it. However, per confirmation from upstream maintainer Jan Friesse (2026-08-31), this protection is a configurable default rather than an enforced control on RHEL <=10 -- it can be turned off via the officially supported pcs interface itself (cipher=none/hash=none), not only via unsupported manual editing. Since a supported configuration path exists to disable it, Red Hat publishes the worst-case supported configuration score rather than crediting the default. See statement for full detail.
Understanding the Weakness (CWE)
Availability
Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory)
Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity,Confidentiality,Availability,Access Control
Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Modify Memory
Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.
Integrity,Confidentiality,Availability,Access Control,Other
Technical Impact: Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Other
When the consequence is arbitrary code execution, this can often be used to subvert any other security service.
Acknowledgements
Red Hat would like to thank Tristan Madani (Talence Security) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
