A stack-based buffer overflow in the illumos reparse point daemon (reparsed) allows a local user to crash the daemon. getfslocations() in usr/src/cmd/fs.d/nfs/rpbasic/libnfsbasic.c, part of the nfs-basic reparse plugin, copies the host and path components of a reparse string into a fixed 1024-byte stack buffer without checking their length. The reparsed door at /var/run/reparseddoor is readable by all users and the door server does not check the caller's credentials, so an unprivileged local user can send an nfs-basic request with an overlong host or path component to overflow the buffer. On systems built with stack protection, which is the default, this causes reparsed to abort; repeated requests place the svc:/system/filesystem/reparse service into maintenance. The service is disabled by default. The flaw has existed since 2009 (illumos-gate commit 2f172c55), and affects any illumos distribution prior to illumos-gate commit 6a2df4aa.

A reachable assertion in the illumos bhyve instruction emulator allows a guest to panic the host. When emulating a REP-prefixed MOVS or STOS instruction that accesses guest MMIO, vieemulatemovs() and vieemulatestos() in usr/src/uts/intel/io/vmm/vmminstructionemul.c do not clear the VIESREPEAT status flag on the final iteration. For MMIO regions emulated in the kernel (the local APIC, I/O APIC and HPET), the stale flag causes a VERIFY assertion in vieadvancepc() to fail, and the host panics. A privileged user within a guest VM can issue a REP MOVS or REP STOS instruction against the local APIC page to cause a denial of service of the host and every other guest running on it. The flaw has existed since 2020 (illumos-gate commit e0c0d44e), and affects any illumos distribution prior to illumos-gate commit 696ecf8d.

Per https://illumos.topicbox.com/groups/developer/T697a32b688807e56-Mf889eb5783e975446573b373/cve-2026-102916-18491-bhyve-rep-prefix-instr-emulation-fumbles-flags illumos would like to report the following CVE:

CVE-2026-102916 18491 bhyve: rep prefix instr emulation fumbles flags

This was discovered by Emily Albini, and fixed by iximeow, both of Oxide Computer.

Thank you, Dan McDonald, on behalf of illumos security

Per https://illumos.topicbox.com/groups/developer/T3b859664594b7762-Maa764f8552227c7080bcaabc/cve-2026-104112-to-cve-2026-104117-denial-of-service-and-missing-authorization-in-door-servers illumos would like to report the following CVEs:

CVE-2026-104112 18494 nscd: unbounded file descriptor allocation

CVE-2026-104113 ipmgmtd double-frees caller credentials on authorization failure (OmniOS and SmartOS only, no general illumos issue)

CVE-2026-104114 18495 Empty nwamd Door payload allows Denial of Service

CVE-2026-104115 18496 Unauthenticated Stack Overflow in reparsed

CVE-2026-104116 18493 Missing doorucred Check in zonestatd

CVE-2026-104117 18492 Missing Authorization in ipmgmtd Allows IPMP Reconfiguration

These were all discovered by Robert French and James Wynne III.

Thank you, Dan McDonald, on behalf of illumos security

A missing authorization check in the illumos zones statistics daemon (zonestatd) allows a local user in any zone to disrupt zonestat in other zones and to determine which zones are running. The zonestatd door server procedure, zsdserver() in usr/src/cmd/zonestat/zonestatd/zonestatd.c, handles the ZSDCMDNEWZONE command, which is intended to be sent by zoneadmd, without checking the caller's credentials. Because the zonestatd door is accessible to all users in every zone, an unprivileged user can send this command with an arbitrary zone ID, causing zonestatd to re-create its door file in that zone, so that new zonestat requests in that zone can fail while the file is replaced. The time taken to handle the command also reveals whether a given zone ID belongs to a running zone. The flaw has existed since 2010 (illumos-gate commit efd4c9b6), and affects any illumos distribution prior to illumos-gate commit 865b58d2.

A missing release of resources in the illumos name service cache daemon (nscd) allows a local user to exhaust kernel memory. The nscd door server procedure, switcher() in usr/src/cmd/nscd/nscdfrontend.c, does not close file descriptors that are passed with a door call but not used by the request, and the main nscd door at /var/run/nameservicedoor accepts passed descriptors from any user in its zone. Because nscd also runs with an unlimited file descriptor limit, an unprivileged local user, including one in a non-global zone, can repeatedly pass a descriptor to its zone's nscd in a doorcall() loop, causing the file descriptor table of nscd to grow without bound in kernel memory. This causes a denial of service of nscd and can render processes in all zones on the host unresponsive. The flaw has existed since 2006 (illumos-gate commit cb5caa98), and affects any illumos distribution prior to illumos-gate commit af810a72.

A NULL pointer dereference in the illumos Network Auto-Magic daemon (nwamd) allows a local user to crash the daemon. nwamddoorswitch() in usr/src/cmd/cmd-inet/lib/nwamd/doorif.c writes to the caller's request structure before checking that a request was supplied, and before checking the caller's credentials. Because the nwamd door at /etc/svc/volatile/nwam/nwamdoor is accessible to all local users, an unprivileged user can issue a doorcall() with no argument data to crash nwamd; repeated calls place the svc:/network/physical:nwam service into maintenance, stopping automatic network configuration. nwamd runs only when svc:/network/physical:nwam is enabled, which is not the default. The flaw has existed since 2010 (illumos-gate commit 6ba597c5), and affects any illumos distribution prior to illumos-gate commit 0f1064d9.

A missing authorization check in the illumos IP management daemon (ipmgmtd) allows a local user to change the persistent IP multipathing (IPMP) configuration. The ipmgmtd door dispatch table in usr/src/cmd/cmd-inet/lib/ipmgmtd/ipmgmtdoor.c does not require the solaris.network.interface.config authorization for the IPMGMTCMDIPMPUPDATE command, although its handler, ipmgmtipmpupdatehandler(), writes to the persistent ipadm configuration when the IPMGMTPERSIST flag is set. An unprivileged local user can therefore add interfaces to, or remove them from, existing IPMP groups in the stored configuration. The running configuration is not changed; the modification takes effect when the stored configuration is next applied, such as at boot, and may disrupt network connectivity. The flaw has existed since 2021 (illumos-gate commit a73be61a), and affects any illumos distribution prior to illumos-gate commit e8d3efa1.

https://bugzilla.redhat.com/showbug.cgi?id=2462085 [CVE-2026-16277] & https://bugzilla.redhat.com/showbug.cgi?id=2502719 [CVE-2026-16461] disclose a pair of related buffer overflows in the rpcinfo command from ONC RPC (aka Sun NFS) when parsing & printing the information returned from a remote rpcbind server.

CVE-2026-16277 covers an overflow when using the -l option: c char buf[128]; sprintf (buf, "%s/%s/%s ", re->rncprotofmly, re->rncproto, re->rncsemantics == NCTPICLTS ? "clts" : re->rncsemantics == NCTPICOTS ? "cots" : "cotsord"); CVE-2026-16461 covers another overflow when using the -s option: c char buf[256]; char p = buf; for (vl = rs->vlist; vl; vl = vl->next) { sprintf (p, "%d", vl->vers); p = p + strlen (p); if (vl->next) sprintf (p++, ","); } The bug reports note they were generated with AI analysis. Red Hat credits Aisle Research for reporting both issues, and Michalis Vasileiadis (GitHub: vmihalis) for reporting CVE-2026-16277 in their advisories at: https://access.redhat.com/security/cve/cve-2026-16277 https://access.redhat.com/security/cve/cve-2026-16461

A fix for CVE-2026-16277 for Linux NFS is published at: https://git.linux-nfs.org/?p=steved/rpcbind.git;a=commitdiff;h=bb9bb7286a4c345442946dc2ce3c9e7f67e96d4d Unfortunately, that server seems overloaded and I haven't found if it has a fix for CVE-2026-16461 or not yet.

NetBSD appears to have fixed both in 2011: https://github.com/NetBSD/src/commit/e95e36baeccc24159378f422fd3dffb97979b415

OpenBSD's rpcinfo does not support the affected options (it uses -s for a different function, and has no -l option).

Fixes for both for OpenSolaris-based distros were integrated in 2010: https://github.com/illumos/illumos-gate/commit/791dfaa708ef5838f55bf4e97e7c960beb186419

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

The illumos SCTP inbound path performs association lookup for INIT ACK chunks without adequately validating the address parameters carried in the chunk. Since this lookup runs during packet classification (i.e. before SCTP integrity checks or IPsec policy are applied) a remote, unauthenticated attacker can send a crafted SCTP INIT ACK packet with malformed address parameters to cause an out-of-bounds access and kernel heap corruption, which may lead to remote code execution. The flaw has existed since 2010 (illumos-gate commit a5407c02), and affects any illumos distribution prior to illumos-gate commit 53a3efde.

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

An issue was discovered in Illumos in Nexenta NexentaStor 4.0.5 and 5.1.2, and other products. The SMB server allows an attacker to have unintended access, e.g., an attacker with WRITEXATTR can change permissions. This occurs because of a combination of three factors: ZFS extended attributes are used to implement NT named streams, the SMB protocol requires implementations to have open handle semantics similar to those of NTFS, and the SMB server passes along certain attribute requests to the underlying object (i.e., they are not considered to be requests that pertain to the named stream).

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.

illumos illumos-gate before 676abcb has a stack buffer overflow in /dev/net, leading to privilege escalation via a stat on a long file name in /dev/net.

In illumos illumos-gate 2024-02-15, an error occurs in the elliptic curve point addition algorithm that uses mixed Jacobian-affine coordinates, causing the algorithm to yield a result of POINTATINFINITY when it should not. A man-in-the-middle attacker could use this to interfere with a connection, resulting in an attacked party computing an incorrect shared secret.

On Intel CPUs sysret to non-canonical address causes a fault on the sysret instruction itself after the stack pointer is set to guest value but before the CPL is changed. Systems running on AMD CPUs are not vulnerable to this issue as sysret on AMD CPUs does not generate a fault before the CPL change.

On Xen, a privileged user on a 64 bit PV guest kernel running on a 64 bit hypervisor could use this flaw to escalate privileges to that of the host. Depending on the particular guest kernel it is also possible that non-privileged guest users could also elevate their privileges to that of the host.

For Red Hat Enterprise Linux guests, only privileged guest users can exploit this issue. HVM guests and 32-bit PV guests cannot be used to exploit this issue.

Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue. Upstream acknowledges Rafal Wojtczuk as the original reporter.

The devzvolreaddir function in illumos does not check the return value of a strchr call, which allows remote attackers to cause a denial of service (NULL pointer dereference and panic) via unspecified vectors.

illumos smbsrv NULL pointer dereference allows system crash.

illumos osnet-incorporation bcopy() and bzero() implementations make signed instead of unsigned comparisons allowing a system crash.

An issue was discovered in illumos before 2020-10-22, as used in OmniOS before r151030by, r151032ay, and r151034y and SmartOS before 20201022. There is a buffer overflow in parseusername in lib/libpam/pamframework.c.