A heap-based buffer overflow in Stream Control Transmission Protocol (SCTP) INIT ACK packet processing in the Helios operating system, which runs on the compute sleds of every Oxide rack, allows a remote unauthenticated attacker to corrupt kernel memory via a single crafted SCTP packet. Successful exploitation can cause a compute sled to panic, resulting in a denial of service for all instances running on that sled, and may allow remote code execution in the kernel. The vulnerable code runs whenever a sled processes an inbound SCTP packet; no SCTP service needs to be running or listening.
Exposure depends on the Oxide release the rack is running:
Racks running releases earlier than 19.4 are exploitable by any attacker able to deliver SCTP packets to the rack, and should be upgraded immediately.
Racks running release 19.4 or later are not exploitable from outside the rack: the rack switches drop all externally delivered SCTP traffic, blocking the attack vector. The vulnerable kernel code is still present.
Release 22 will include a fixed Helios kernel that removes the vulnerability.
This issue was reported to Oxide externally and has been addressed in the illumos project, the operating system community that Helios is built on. It is tracked as CVE-2026-15422. For upstream details, see the illumos security advisory.
| Revision | Date (YYYYMMDD) | Changes |
|---|---|---|
1.0 | 20260716 | Initial Release |
Impacted Products
Gimlet and Cosmo compute sleds running Oxide releases earlier than 19.4 are remotely exploitable.
Gimlet and Cosmo compute sleds running Oxide release 19.4 or later contain the vulnerable kernel code, but it cannot be reached from outside the rack because the switch drops all externally delivered SCTP traffic (see dendrite#262).
The kernel fix is included in Helios 3.0.24088 and will ship in Oxide release 22.
Impact
An unauthenticated remote attacker who can deliver a specially crafted SCTP INIT ACK packet to a compute sled can trigger a kernel heap buffer overflow, corrupting kernel memory. Successful exploitation may result in a kernel panic of the sled, other system-wide denial of service conditions, or remote code execution in the kernel. A panic or compromise of a compute sled affects every instance running on that sled.
No authentication, established SCTP association, or listening SCTP service is required: the vulnerable code runs during inbound packet classification, before any protocol integrity checks are applied.
Action Required
Customers running releases earlier than 19.4 should upgrade to release 19.4 or later immediately. Release 19.4 introduced filtering on the rack switches that drops all externally delivered SCTP traffic (see dendrite#262), preventing exploitation of this vulnerability from outside the rack.
All customers should plan to upgrade to release 22 once it becomes available, which includes the Helios kernel fix that removes the vulnerability itself.
Mitigations
Customers who cannot upgrade to release 19.4 or later immediately should block or filter SCTP traffic destined for the rack in their upstream network infrastructure until the upgrade is complete.
Technical Background
When the Helios kernel receives an SCTP INIT ACK chunk, it performs an association lookup that parses the address parameters carried in the chunk. During this parsing, the kernel calculates the number of address entries from the total parameter size rather than from the number of parameters actually processed. A specially crafted packet can therefore cause writes beyond the end of an allocated buffer, corrupting kernel heap memory (CWE-122 heap-based buffer overflow, CWE-787 out-of-bounds write).
Because this lookup runs during inbound packet classification — before SCTP integrity checks or IPsec policy are applied — exploitation requires no established association, no listening SCTP service, and no authentication. The flaw has been present in the illumos SCTP implementation since 2010 and was fixed upstream in illumos-gate commit 53a3efde, which is included in Helios 3.0.24088.