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.
There is no complete mitigation for this vulnerability short of a fix, but the following steps reduce risk:
- Ensure cluster message authentication is enabled in corosync.conf (crypto_cipher=aes256, crypto_hash=sha256 with a shared key from corosync-keygen), which is the default when clusters are configured via 'pcs cluster setup', and disabling it (cipher=none/hash=none) is an explicitly unsupported configuration per upstream maintainer guidance.
- Restrict network access to the cluster communication ports (default 5405-5412/UDP) to trusted cluster node addresses only.
- Where architecturally feasible, prefer 64-bit deployments, since the integer overflow described here does not occur on 64-bit systems.