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

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.

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.

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.

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.

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.

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.

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.