Bug 2513314 (CVE-2026-68162)

Summary:	CVE-2026-68162 kernel: sctp: avoid auth_enable sysctl UAF during netns teardown
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	akhatavk, akito5623, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Stream Control Transmission Protocol (SCTP) implementation within the Linux kernel. This Use-After-Free (UAF) vulnerability occurs during network namespace (netns) teardown. A local attacker with the ability to open a sysctl file could exploit this flaw, potentially leading to a system crash or other undefined behavior due to memory corruption.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-10 12:30:26 UTC

In the Linux kernel, the following vulnerability has been resolved:

sctp: avoid auth_enable sysctl UAF during netns teardown

proc_sctp_do_auth() updates the SCTP control socket after changing
net.sctp.auth_enable. The handler gets the per-net SCTP state from
ctl->data, so an already opened sysctl file can still target a network
namespace while that namespace is being torn down.

SCTP previously registered its per-net sysctls from sctp_defaults_init(),
while the control socket is created later from sctp_ctrlsock_init(). This
exposed a window during initialization where auth_enable was writable
before net->sctp.ctl_sock existed, and a teardown window where auth_enable
stayed writable after inet_ctl_sock_destroy() had released the control
socket.

Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after
sctp_ctl_sock_init() succeeds, and unregister the sysctl table before
destroying the control socket in sctp_ctrlsock_exit(). If sysctl
registration fails after the control socket was created, destroy the
control socket in the same init path.

Make sctp_sysctl_net_unregister() tolerate a missing header and clear the
saved pointer so init-error and exit paths can safely share the unregister
helper.

Comment 6 Akiyoshi Kurita 2026-08-29 13:41:24 UTC

A public exploit for CVE-2026-68162 is now available.

Public exploit:
[https://github.com/NebuSec/CyberMeowfia/tree/main/security-research/Linux-CVE-2026-68162-Ubuntu-7.0.0-28](https://github.com/NebuSec/CyberMeowfia/tree/main/security-research/Linux-CVE-2026-68162-Ubuntu-7.0.0-28)

Demo video:
[https://x.com/nebusecurity/status/2093581170655260730](https://x.com/nebusecurity/status/2093581170655260730)

Upstream CVE announcement / patch:
[https://lore.kernel.org/linux-cve-announce/2026081004-CVE-2026-68162-086a@gregkh/T/#u](https://lore.kernel.org/linux-cve-announce/2026081004-CVE-2026-68162-086a@gregkh/T/#u)

Red Hat CVE page:
[https://access.redhat.com/security/cve/cve-2026-68162](https://access.redhat.com/security/cve/cve-2026-68162)

I also reviewed the relevant kernel code paths.

My current assessment is as follows.

RHEL 6 and RHEL 7:
The vulnerable upstream change appears to have been introduced into newer stable kernel branches starting from the 5.4 series. Unless an equivalent change was separately backported by Red Hat, RHEL 6 and RHEL 7 may not be affected.

RHEL 8 and RHEL 9:
I could not identify the vulnerable code path in the kernel sources I checked. In particular, proc_sctp_do_auth() still uses current->nsproxy->net_ns rather than the vulnerable ctl->data-based code path.

RHEL 10:
The vulnerable SCTP code path appears to be present, so RHEL 10 appears to be affected.

Could Red Hat please re-check the affectedness of RHEL 6, RHEL 7, RHEL 8, and RHEL 9 for CVE-2026-68162?

Also, if SCTP is not required, would preventing the sctp kernel module from loading be a valid mitigation?

echo 'install sctp /bin/false' > /etc/modprobe.d/disable-sctp.conf

Comment 7 Akiyoshi Kurita 2026-08-29 13:50:25 UTC

Correction to Comment 6:

The formatting in Comment 6 was broken because the URLs were posted using Markdown-style link syntax. Please refer to the corrected plain-text version below.

A public exploit for CVE-2026-68162 is now available.

Public exploit:
https://github.com/NebuSec/CyberMeowfia/tree/main/security-research/Linux-CVE-2026-68162-Ubuntu-7.0.0-28

Demo video:
https://x.com/nebusecurity/status/2093581170655260730

Upstream CVE announcement / patch:
https://lore.kernel.org/linux-cve-announce/2026081004-CVE-2026-68162-086a@gregkh/T/#u

Red Hat CVE page:
https://access.redhat.com/security/cve/cve-2026-68162

I also reviewed the relevant kernel code paths.

My current assessment is as follows.

RHEL 6 and RHEL 7:
The vulnerable upstream change appears to have been introduced into newer stable kernel branches starting from the 5.4 series. Unless an equivalent change was separately backported by Red Hat, RHEL 6 and RHEL 7 may not be affected.

RHEL 8 and RHEL 9:
I could not identify the vulnerable code path in the kernel sources I checked. In particular, proc_sctp_do_auth() still uses current->nsproxy->net_ns rather than the vulnerable ctl->data-based code path.

RHEL 10:
The vulnerable SCTP code path appears to be present, so RHEL 10 appears to be affected.

Could Red Hat please re-check the affectedness of RHEL 6, RHEL 7, RHEL 8, and RHEL 9 for CVE-2026-68162?

Also, if SCTP is not required, would preventing the sctp kernel module from loading be a valid mitigation?

echo 'install sctp /bin/false' > /etc/modprobe.d/disable-sctp.conf