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.

Corosync is a group communication system providing reliable ordered messaging and membership services, and is the communication layer underlying Pacemaker HA clusters (RHEL High Availability Add-On). In exec/totempg.c, the totempgdeliverfn function reassembles fragmented multicast messages into a fixed-size per-node assembly buffer (struct assembly, data[MESSAGESIZEMAX + KNETMAXPACKETSIZE], ~1.06 MB on normal builds, ~128 KB on small-memory-footprint builds). The only bounds check before the memcpy at line 663 is an assert() at line 662, which is compiled out in release builds (-DNDEBUG). assembly->index grows unboundedly at line 737 for each continuation fragment with no upper-bound check. After 17-18 fragments on normal builds (3 fragments on small-memory-footprint builds), the memcpy writes attacker-controlled data past the end of the heap buffer.

Verified via an ASan-instrumented standalone harness reproducing the exact buffer layout and memcpy/index logic: after 17 fragments of 65,481 bytes each, assembly->index reached 1,113,177 (buffer capacity 1,114,112); fragment 18 triggered a confirmed heap-buffer-overflow WRITE of 65,481 bytes, 64,546 bytes past the buffer end.

Present in corosync v3.1.10 (latest upstream release) and main HEAD (commit 65235a8); no upstream fix exists for this bug. Reported by Tristan Madani (Talence Security) via PSIRTSUPT-22352.

A flaw was found in Corosync. An integer overflow vulnerability in Corosync's join message sanity validation allows a remote, unauthenticated attacker to send crafted User Datagram Protocol (UDP) packets. This can cause the service to crash, leading to a denial of service. This vulnerability specifically affects Corosync deployments configured to use totemudp/totemudpu mode.

Integer overflow (wraparound) vulnerability in Corosync’s join message sanity validation in exec/totemsrp.c. The flaw is in checkmembjoinsanity(), where proclistentries and failedlistentries are attacker-controlled 32-bit unsigned values received from the network and are added together before being promoted to sizet. This allows the addition (proclistentries + failedlistentries) to wrap around in 32-bit arithmetic (e.g., 0x80000000 + 0x80000000 = 0), causing requiredlen to be calculated too small and allowing a short packet to pass validation. As a result, Corosync proceeds with processing malformed input that should have been rejected, which can be exploited remotely without authentication in totemudp/totemudpu mode via crafted UDP packets to crash the service, resulting in a denial of service.

A flaw was found in Corosync. A remote unauthenticated attacker can exploit a wrong return value vulnerability in the Corosync membership commit token sanity check by sending a specially crafted User Datagram Protocol (UDP) packet. This can lead to an out-of-bounds read, causing a denial of service (DoS) and potentially disclosing limited memory contents

Wrong return value vulnerability in the Corosync membership commit token sanity check in exec/totemsrp.c. The flaw occurs in checkmembcommittokensanity() where truncated messages (msglen < sizeof(struct membcommittoken)) incorrectly return 0 (success) instead of -1 (failure). As a result, messagehandlermembcommittoken() continues processing attacker-controlled, undersized input, performs an allocation based on the short length, and then accesses struct membcommittoken fields beyond the allocated region, triggering an out-of-bounds read (ASAN-confirmed). This can be exploited remotely without authentication in totemudp/totemudpu mode by sending a single crafted UDP packet to the Corosync port (default 5405), causing a denial of service and potentially leaking limited memory contents.

Corosync through 3.1.9, if encryption is disabled or the attacker knows the encryption key, has a stack-based buffer overflow in orftokenendianconvert in exec/totemsrp.c via a large UDP packet.

corosync before version 2.4.4 is vulnerable to an integer overflow in exec/totemcrypto.c.

The initnsshash function in exec/totemcrypto.c in Corosync 2.0 before 2.3 does not properly initialize the HMAC key, which allows remote attackers to cause a denial of service (crash) via a crafted packet.