CVE-2026-35091: 
NixOS vulnerability analysis and mitigation

CVE-2026-35091 is a wrong return value / out-of-bounds read vulnerability in the Corosync Cluster Engine affecting the membership commit token sanity check (check_memb_commit_token_sanity() in exec/totemsrp.c). A remote unauthenticated attacker can send a single specially crafted UDP packet to crash the Corosync service and potentially disclose limited memory contents. The vulnerability affects Corosync running in totemudp/totemudpu mode, which is the default configuration, and impacts distributions including Red Hat Enterprise Linux 7–10, Fedora 42–44, Ubuntu, Debian, openSUSE, and Amazon Linux 2023. It was reported on March 30, 2026 by Sebastian Alba Vives and publicly disclosed on April 1, 2026, with a CVSS v3.1 base score of 8.2 (High) (Red Hat CVE, Github Advisory).

The root cause is an incorrect function return value check (CWE-253) in check_memb_commit_token_sanity(): when the received message length is less than sizeof(struct memb_commit_token), the function incorrectly returns 0 (success) instead of -1 (failure), unlike the analogous check_orf_token_sanity() which correctly returns -1. This causes message_handler_memb_commit_token() to continue processing the attacker-controlled, undersized input — it allocates memory based on the short length and then reads struct memb_commit_token fields beyond the allocated region, triggering a heap-buffer-overflow read (CWE-125, ASAN-confirmed). No authentication or prior cluster membership is required; a single UDP packet to the Corosync port (default UDP/5405) is sufficient to trigger the flaw. The fix is a one-line change: replacing return (0) with return (-1) at approximately line 3814 of exec/totemsrp.c (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation causes a denial of service by crashing the Corosync cluster engine process, which can disrupt high-availability cluster operations and take down dependent services (e.g., Pacemaker-managed resources). Additionally, the out-of-bounds read may leak limited heap memory contents to the attacker, posing a low-severity confidentiality risk. Because Corosync is a foundational component of Linux HA clusters (used in RHEL, OpenShift, and cloud environments), a crash can have cascading availability impacts across clustered workloads. There is no integrity impact and no evidence of code execution capability from this specific flaw (Red Hat CVE, Github Advisory).

A proof-of-concept (PoC) exploit in C (harness_bug1_minimal.c) was attached to the Red Hat Bugzilla report at the time of disclosure, with ASAN output confirming the heap-buffer-overflow read; it can be compiled with gcc -fsanitize=address,undefined -g -O0 harness_bug1_minimal.c -o harness_bug1 and run to reproduce the crash (Red Hat Bugzilla PoC). The EPSS score is approximately 0.34%, indicating a low but non-negligible probability of exploitation in the wild within 30 days. No in-the-wild exploitation or threat actor attribution has been reported as of the time of this report, and the vulnerability is not listed in the CISA KEV catalog. The attack requires no authentication and no user interaction, making it trivially exploitable against any internet- or network-exposed Corosync instance running in the default totemudp/totemudpu mode (Feedly).

1. Reconnaissance: Identify hosts running Corosync in totemudp/totemudpu mode (the default). Use network scanning tools (e.g., Nmap, Shodan) to locate systems with UDP port 5405 open, which is the default Corosync cluster communication port.
2. Craft malicious UDP packet: Construct a UDP packet destined for port 5405 that contains a memb_commit_token message type header but with a payload shorter than sizeof(struct memb_commit_token). The packet must be formatted to pass initial Corosync message framing checks while having an undersized body.
3. Send the packet: Transmit the crafted UDP packet to the target's Corosync port (UDP/5405) from any network-reachable host. No authentication or cluster membership is required.
4. Trigger out-of-bounds read: Corosync's check_memb_commit_token_sanity() incorrectly returns 0 (success) for the truncated message, causing message_handler_memb_commit_token() to allocate memory based on the short length and then read struct fields beyond the allocation boundary.
5. Achieve DoS / memory disclosure: The out-of-bounds read causes a crash (SIGSEGV or heap corruption), terminating the Corosync process and disrupting cluster operations. Depending on memory layout, limited heap contents adjacent to the allocation may be observable in error output or via a network response (Red Hat Bugzilla PoC).

• Network: Unexpected or repeated UDP packets to port 5405 from external or untrusted IP addresses; single-packet bursts with undersized payloads targeting the Corosync port.
• Logs: Corosync crash logs or core dumps in /var/log/cluster/ or system journal (journalctl -u corosync); ASAN-style heap-buffer-overflow messages if debug builds are deployed; kernel messages indicating process crash (e.g., corosync[PID]: segfault).
• Process: Unexpected termination or restart of the corosync process; cluster fencing events or resource failovers triggered by Corosync unavailability as reported by Pacemaker logs.
• File System: Unexpected core dump files (e.g., core.*) in the working directory of the Corosync process, typically /var/lib/corosync/ or /.

Red Hat has released patched packages across all affected RHEL versions: RHSA-2026:13644 (RHEL 10), RHSA-2026:13657 (RHEL 8), RHSA-2026:13673 (RHEL 9), RHSA-2026:14205–14216 (various EUS/SAP/TUS streams), RHSA-2026:19043, RHSA-2026:19200, and RHSA-2026:20916 (RHEL 7 ELS) (Red Hat Errata). Fedora fixes were released as corosync-3.1.10-2.fc43, corosync-3.1.9-4.fc42, and corosync-3.1.10-5.fc44; Ubuntu issued USN-8170-1; Debian issued DSA-6261-1 and DLA-4608-1; Amazon Linux 2023 issued ALAS2023-2026-1560 (Github Advisory). As an immediate workaround, restrict network access to UDP port 5405 using firewall rules so that only trusted cluster nodes can communicate with Corosync, significantly reducing the attack surface. Upgrading to a patched package version is the definitive remediation.

The vulnerability was reported by security researcher Sebastian Alba Vives (@Sebasteuo / 0xS4bb1) with a 90-day disclosure deadline, and Red Hat coordinated the response through their Product Security team (Red Hat Bugzilla). The disclosure generated moderate community attention, with coverage on security aggregators including linuxsecurity.com, pro-linux.de, and redpacketsecurity.com, as well as social media posts on Mastodon and Bluesky. Multiple Linux distributions (RHEL, Fedora, Ubuntu, Debian, openSUSE, Amazon Linux, AlmaLinux, Rocky Linux, Oracle Linux) coordinated patch releases, reflecting the broad ecosystem impact of a flaw in a core HA clustering component.