REDHAT-BUG-2524923: Medium severity Corosync vulnerability
In exec/totemsrp.c, checkmembcommittokensanity() computes requiredlen = sizeof(struct membcommittoken) + (addrentries (sizeof(struct srpaddr) + sizeof(struct membcommittokenmembentry))), where addrentries is an attacker-controlled 32-bit field taken from a network packet and the per-entry size is 28 bytes. On architectures where sizet is 32-bit, this multiplication can overflow when addrentries >= 153,391,690, wrapping requiredlen to a small value and allowing a short (~100-byte) crafted packet to pass the length check. The subsequent membcommittokenendianconvert() then loops addrentries times over a small buffer, causing an out-of-bounds read/write and an immediate crash (denial of service).
This is the same vulnerability class as CVE-2026-35092, whose fix added a PROCESSORCOUNTMAX bounds check and explicit sizet casts to checkmembjoinsanity() only; checkmembcommittokensanity() was not fixed and remains vulnerable in both corosync v3.1.10 and main HEAD (confirmed via diff between the two).
On 64-bit architectures (x8664, aarch64), C integer-promotion rules cause the multiplication to be evaluated in 64-bit arithmetic (since sizeof() returns sizet), so the overflow does not occur and the check correctly rejects the malformed packet. Verified with a standalone arithmetic harness: with addrentries=153,391,690, the 32-bit product wraps to 24 (requiredlen=65, incorrectly passes a 100-byte packet), while the 64-bit product correctly computes to 4,294,967,320 (requiredlen=4,294,967,361, correctly rejects). The PROCESSORCOUNTMAX(384) bounds check from the CVE-2026-35092 fix would also correctly reject this input if applied here. Reported by Tristan Madani (Talence Security) via PSIRTSUPT-22352.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In check_memb_commit_token_sanity(), ensure addr_entries is range-checked with PROCESSOR_COUNT_MAX(384) (as in the CVE-2026-35092 fix) and force the multiplication to be performed in size_t to prevent 32-bit overflow wrapping; this specific function is stated as not fixed in v3.1.10 and main HEAD.
corosync (exec/totemsrp.c) check_memb_commit_token_sanity() PROCESSOR_COUNT_MAX bounds check and explicit size_t casts for required_len calculation = Apply PROCESSOR_COUNT_MAX(384) bounds check to addr_entries and cast operands to size_t before computing required_len = sizeof(struct memb_commit_token) + (addr_entries * (sizeof(struct srp_addr) + sizeof(struct memb_commit_token_memb_entry))). - Compensating control
If patching is not immediately possible, apply a compensating network/ACL control to prevent or restrict sending crafted SRP packets that reach exec/totemsrp.c (the vulnerability is triggered by an attacker-controlled addr_entries field in a network packet).
Event History
Frequently Asked Questions
Which deployments are affected by the integer overflow condition?
The issue affects Corosync on architectures where size_t is 32-bit. The description states that corosync v3.1.10 and main HEAD remain vulnerable in check_memb_commit_token_sanity().
What must an attacker supply to trigger the crash?
An attacker needs to send a crafted network packet with the attacker-controlled addr_entries field set to at least 153,391,690. On a 32-bit size_t platform, this can allow a short packet of roughly 100 bytes to pass the length check before out-of-bounds processing occurs.
Does the fix associated with CVE-2026-35092 address this path?
No. That fix added bounds and size_t handling to check_memb_join_sanity() only; check_memb_commit_token_sanity() was not fixed.