Fedora Account System
Red Hat Associate
Red Hat Customer
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.
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
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