illumos distros should hotpatch or update to prevent a potential privilege escalation.

OmniOS has already dropped updates via IPS.

SmartOS has JUST respun last week's biweekly release today to add this fix. Next week's biweekly release will still ship, but with other upstream merges as well.

Other illumos distributions have been informed as well, and ones like OpenIndiana follow illumos-gate very closely.

Thanks, Dan

Begin forwarded message:

From: Dan McDonald <danmcd () Edgecast io> Subject: [developer] 18118 SCTP frees wrong-size, and need to keep private options Date: May 22, 2026 at 11:46:10 AM EDT To: illumos-developer <developer () lists illumos org> Reply-To: illumos-developer <developer () lists illumos org>

Hi folks,

illumos#18118 addresses two related vulnerabilities in the SCTP socket ioctl path, both reachable by any unprivileged process that can open an SCTP socket. The first is a heap memory corruption in the SIOCSCTPSOPT ioctl, where a buffer is allocated with one size but freed with a different (user-controlled) size on the error path. The second exposes the kernel-private SCTPUCSWAP socket option to userspace, allowing an unprivileged caller to overwrite the SCTP socket's upcall handle and upcall function table with arbitrary values.

Distributions shipping illumos with SCTP enabled should treat this as a high-priority update. Anyone running on systems where untrusted local users (or zone tenants) can execute code should be especially attentive.

IMPACT: Both bugs are reachable from any unprivileged process with permission to create an SCTP socket, including from within a non-global zone.

The wrong-size kmemfree() lets the caller free a chunk into the wrong kmem cache, which can be steered into corruption of adjacent heap objects.

The SCTPUCSWAP exposure lets the caller install attacker-controlled pointers that the kernel later dereferences and calls. In conjunction with other techniques it could allow kernel-mode instruction-pointer control, leading to local privilege escalation.

At a minimum, either bug can be used to panic the kernel.

ACTION: Please be on the look out for patches from your distribution and be ready to update.

MITIGATIONS: On systems where an immediate kernel update is not yet possible, the SCTPUCSWAP exposure (the more dangerous of the two issues) can be mitigated on a running gcc10-compiled non-DEBUG kernel with a small hotpatch that rewrites the SCTPUCSWAP case in sctpsetopt() to fall through to the EINVAL error path. This will break the in-kernel SCTP peel-off path that legitimately relies on SCTPUCSWAP, but unprivileged abuse of the option is closed off. The wrong-size kmemfree() bug does not have a clean hotpatch and requires the full fix.

Before applying, confirm that the disassembly around sctpsetopt+0x598 matches the following on your running kernel:

mdb -ke 'sctpsetopt+0x598::dis' sctpsetopt+0x570: setne %dl sctpsetopt+0x573: andl $0x7f,%eax sctpsetopt+0x576: shll $0x7,%edx sctpsetopt+0x579: orl %edx,%eax sctpsetopt+0x57b: movb %al,0x538(%rbx) sctpsetopt+0x581: jmp -0x34e <sctpsetopt+0x238> sctpsetopt+0x586: nop sctpsetopt+0x588: cmpl $0x17,%r15d sctpsetopt+0x58c: je +0x232 <sctpsetopt+0x7c4> sctpsetopt+0x592: jle +0xe0 <sctpsetopt+0x678> sctpsetopt+0x598: cmpl $0xff,%r15d sctpsetopt+0x59f: jne -0x36d <sctpsetopt+0x238> sctpsetopt+0x5a5: movq 0xfffffffffffffef8(%rbp),%rcx sctpsetopt+0x5ac: movq 0x370(%rbx),%rax sctpsetopt+0x5b3: movq (%rcx),%rdx sctpsetopt+0x5b6: movq %rdx,0x1b0(%rax) sctpsetopt+0x5bd: movq 0x370(%rbx),%rax sctpsetopt+0x5c4: movq 0x8(%rcx),%rdx sctpsetopt+0x5c8: movq %rdx,0x1a8(%rax) sctpsetopt+0x5cf: jmp -0x39c <sctpsetopt+0x238>

If the disassembly matches, apply the hotpatch as root@global-zone:

===================== (Cut up to and including here.) ===================== mdb -kwe 'sctpsetopt+0x598/w0xfeeb mdb -kwe 'sctpsetopt+0x5a0/W0xfffffc mdb -kwe 'sctpsetopt+0x598/Z0x95e900000063b841 ===================== (Cut up to and including here.) =====================

After patching, the SCTPUCSWAP case should disassemble as:

sctpsetopt+0x598: movl $0x63,%r8d sctpsetopt+0x59e: jmp -0x36b <sctpsetopt+0x238>

which loads ENOPROTOOPT (99 / 0x63) into the retval register and jumps to the common error-return path. If your kernel does not match the expected disassembly (different compiler, DEBUG build, or already-fixed version), do NOT apply the hotpatch - reach out and we will help work out the correct offsets for your build.

Please reach out to us if you have any questions, whether on the mailing list, IRC, or otherwise, and we'll try to help as we can.

We'd like to thank Sourque for finding and responsibly disclosing these issues, and Dan McDonald for the analysis and fix, and Andy Fiddaman for the announcement text and improved hotpatch.

The illumos Security Team

------------------------------------------ illumos: illumos-developer Permalink: https://illumos.topicbox.com/groups/developer/T9e4049ae8de3721a-M0fb3904f868a79087a841b6b Delivery options: https://illumos.topicbox.com/groups/developer/subscription

Openindiana, kernel SunOS 5.11 has a denial of service vulnerability. For the processing of TCP packets with RST or SYN flag set, Openindiana has a wide acceptable range of sequence numbers. It does not require the sequence number to exactly match the next expected sequence value, just to be within the current receive window, which violates RFC5961. This flaw allows attackers to send multiple random TCP RST/SYN packets to hit the acceptable range of sequence numbers, thereby interrupting normal connections and causing a denial of service attack.

An issue was discovered in illumos before f859e7171bb5db34321e45585839c6c3200ebb90, OmniOS Community Edition r151038, OpenIndiana Hipster 2021.04, and SmartOS 20210923. A local unprivileged user can cause a deadlock and kernel panic via crafted rename and rmdir calls on tmpfs filesystems. Oracle Solaris 10 and 11 is also affected.

bhyve, as used in FreeBSD through 12.1 and illumos (e.g., OmniOS CE through r151034 and OpenIndiana through Hipster 2020.04), does not properly restrict VMCS and VMCB read/write operations, as demonstrated by a root user in a container on an Intel system, who can gain privileges by modifying VMCSHOSTRIP.