Bug 2524923 (CVE-2026-81666)

Summary: CVE-2026-81666 corosync: corosync: integer overflow in check_memb_commit_token_sanity may bypass message length validation on 32-bit systems
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, security-response-team, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-27 10:46:05 UTC 
In exec/totemsrp.c, check_memb_commit_token_sanity() computes required_len = sizeof(struct memb_commit_token) + (addr_entries * (sizeof(struct srp_addr) + sizeof(struct memb_commit_token_memb_entry))), where addr_entries is an attacker-controlled 32-bit field taken from a network packet and the per-entry size is 28 bytes. On architectures where size_t is 32-bit, this multiplication can overflow when addr_entries >= 153,391,690, wrapping required_len to a small value and allowing a short (~100-byte) crafted packet to pass the length check. The subsequent memb_commit_token_endian_convert() then loops addr_entries 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 PROCESSOR_COUNT_MAX bounds check and explicit size_t casts to check_memb_join_sanity() only; check_memb_commit_token_sanity() 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 (x86_64, aarch64), C integer-promotion rules cause the multiplication to be evaluated in 64-bit arithmetic (since sizeof() returns size_t), so the overflow does not occur and the check correctly rejects the malformed packet. Verified with a standalone arithmetic harness: with addr_entries=153,391,690, the 32-bit product wraps to 24 (required_len=65, incorrectly passes a 100-byte packet), while the 64-bit product correctly computes to 4,294,967,320 (required_len=4,294,967,361, correctly rejects). The PROCESSOR_COUNT_MAX(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.