[<prev] [next>] [day] [month] [year] [list]
Message-ID: <157A3B07-0201-4B0A-844E-46AD31FFAF60@edgecast.io>
Date: Fri, 22 May 2026 19:27:27 +0000
From: Dan McDonald <danmcd@...ecast.io>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: illumos: 18118 SCTP frees wrong-size, and need to keep private
options
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@...ecast.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@...ts.illumos.org>
Reply-To: illumos-developer <developer@...ts.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 SCTP_UC_SWAP 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 kmem_free() lets the caller free a chunk into the wrong
kmem cache, which can be steered into corruption of adjacent heap
objects.
The SCTP_UC_SWAP 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 SCTP_UC_SWAP 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 SCTP_UC_SWAP case in
sctp_set_opt() to fall through to the EINVAL error path. This will
break the in-kernel SCTP peel-off path that legitimately relies on
SCTP_UC_SWAP, but unprivileged abuse of the option is closed off. The
wrong-size kmem_free() bug does not have a clean hotpatch and requires
the full fix.
Before applying, confirm that the disassembly around sctp_set_opt+0x598
matches the following on your running kernel:
# mdb -ke 'sctp_set_opt+0x598::dis'
sctp_set_opt+0x570: setne %dl
sctp_set_opt+0x573: andl $0x7f,%eax
sctp_set_opt+0x576: shll $0x7,%edx
sctp_set_opt+0x579: orl %edx,%eax
sctp_set_opt+0x57b: movb %al,0x538(%rbx)
sctp_set_opt+0x581: jmp -0x34e <sctp_set_opt+0x238>
sctp_set_opt+0x586: nop
sctp_set_opt+0x588: cmpl $0x17,%r15d
sctp_set_opt+0x58c: je +0x232 <sctp_set_opt+0x7c4>
sctp_set_opt+0x592: jle +0xe0 <sctp_set_opt+0x678>
sctp_set_opt+0x598: cmpl $0xff,%r15d
sctp_set_opt+0x59f: jne -0x36d <sctp_set_opt+0x238>
sctp_set_opt+0x5a5: movq 0xfffffffffffffef8(%rbp),%rcx
sctp_set_opt+0x5ac: movq 0x370(%rbx),%rax
sctp_set_opt+0x5b3: movq (%rcx),%rdx
sctp_set_opt+0x5b6: movq %rdx,0x1b0(%rax)
sctp_set_opt+0x5bd: movq 0x370(%rbx),%rax
sctp_set_opt+0x5c4: movq 0x8(%rcx),%rdx
sctp_set_opt+0x5c8: movq %rdx,0x1a8(%rax)
sctp_set_opt+0x5cf: jmp -0x39c <sctp_set_opt+0x238>
If the disassembly matches, apply the hotpatch as root@...bal-zone:
===================== (Cut up to and including here.) =====================
mdb -kwe 'sctp_set_opt+0x598/w0xfeeb
mdb -kwe 'sctp_set_opt+0x5a0/W0xfffffc
mdb -kwe 'sctp_set_opt+0x598/Z0x95e900000063b841
===================== (Cut up to and including here.) =====================
After patching, the SCTP_UC_SWAP case should disassemble as:
sctp_set_opt+0x598: movl $0x63,%r8d
sctp_set_opt+0x59e: jmp -0x36b <sctp_set_opt+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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
