CVE-2026-81666: Corosync: corosync: integer overflow in check_memb_commit_token_sanity may bypass message length validation on 32-bit systems
An integer overflow was found in Corosync's handling of membership commit token messages. The length-validation check for these messages can be bypassed on 32-bit systems due to an integer overflow in the calculation of the expected message length, allowing a crafted network packet to trigger an out-of-bounds memory access that crashes the Corosync daemon. This results in a denial of service for the affected cluster node. The overflow does not occur on 64-bit systems, where the length calculation is correctly performed in 64-bit arithmetic.
Other sources
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.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement the same defensive logic described as the CVE-2026-35092 fix: apply the PROCESSOR_COUNT_MAX(384) bounds check to the attacker-controlled addr_entries in check_memb_commit_token_sanity() and use explicit size_t casts so required_len arithmetic is evaluated in 64-bit arithmetic on 32-bit systems as well. This prevents required_len wrapping and blocks short (~100-byte) crafted packets from passing the length validation, avoiding the subsequent out-of-bounds access in memb_commit_token_endian_convert(). (PSIRTSUPT-22352)
Corosync (check_memb_commit_token_sanity / membership commit token handling) PROCESSOR_COUNT_MAX bounds check (as referenced from CVE-2026-35092 fix) = Apply PROCESSOR_COUNT_MAX(384) bounds check to addr_entries before computing required_len; ensure multiplication is performed with explicit size_t casts to avoid 32-bit integer overflow - Operational
After applying the code fix/patch, restart or otherwise recover the affected Corosync daemon to clear any crash/denial-of-service state from malformed membership commit token packets.
Event History
Frequently Asked Questions
Which systems are affected by this issue?
Only Corosync deployments running on 32-bit systems are affected. On 64-bit systems, the message-length calculation uses 64-bit arithmetic and the described overflow does not occur.
Does exploitation require authentication or user interaction?
No. The vector is network-based, with low attack complexity, no privileges required, and no user interaction required; an attacker must be able to send a crafted membership commit token packet to the affected Corosync node.
What is the practical impact of a successful attack?
A crafted short packet can bypass the length check and cause out-of-bounds memory access while Corosync processes attacker-controlled address entries. The stated impact is a crash of the Corosync daemon, causing denial of service for the affected cluster node.
How can I identify malicious or triggering input?
The triggering condition is a membership commit token message with an addr_entries field of at least 153,391,690 on a 32-bit system. The packet can be relatively short, approximately 100 bytes, because the expected-length calculation wraps to a small value.