REDHAT-BUG-2524910: High severity corosync corosync vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Corosync nodes that process fragmented multicast messages are exposed, including Corosync deployments used as the communication layer for Pacemaker HA clusters. The issue affects the per-node message reassembly path.
What does an attacker need to send to trigger the overflow?
An attacker needs to cause a target node to receive enough continuation fragments for a multicast message that the cumulative reassembly length exceeds the fixed assembly buffer. The fragments contain attacker-controlled data that is copied past the heap buffer boundary.
Are release builds affected?
Yes. The relevant bounds check is implemented as an assert(), and asserts are compiled out of release builds built with -DNDEBUG. In that case, the assembly index can grow without an upper-bound check before memcpy.
Does the number of fragments needed vary by build?
Yes. The overflow occurs after approximately 17 to 18 fragments on normal builds, while small-memory-footprint builds can reach the condition after 3 fragments.