Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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.