CVE-2026-68162

What it actually does

This is a Linux kernel SCTP use-after-free involving the per-network-namespace SCTP auth_enable sysctl. An already opened /proc/sys/net/sctp/auth_enable file can continue to reference SCTP per-net state while the associated network namespace is being initialized or torn down. During teardown, the SCTP control socket could be destroyed while the sysctl remained writable, allowing a later write to operate on freed or uninitialized kernel state. Successful triggering can cause kernel memory corruption and system crash, and depending on kernel configuration, allocator behavior, and attacker control of memory reuse, may have privilege-escalation implications. Practical exploitation generally requires local access with the ability to manipulate network namespaces and write the SCTP sysctl, often tied to CAP_NET_ADMIN in the relevant namespace or environments where unprivileged user/network namespaces are enabled.

Why it matters to the business

The most likely business impact is host instability or denial of service from a kernel crash, particularly on Linux systems where containers, sandboxed workloads, or local users can create network namespaces. In higher-risk configurations, the flaw could contribute to local privilege escalation or container boundary weakening. Because it is newly published, not listed in CISA KEV, not known to be used in ransomware, and has no reported public exploit maturity, urgency is lower than for actively exploited kernel flaws, but internet-scale Linux prevalence and common container usage make timely kernel patching important.

How an attack unfolds

An attacker first needs local code execution on a Linux host or inside a workload where they can create and tear down network namespaces and gain sufficient privilege inside that namespace to write network sysctls. They cause SCTP per-net sysctl state to be exposed by loading or using SCTP functionality, open /proc/sys/net/sctp/auth_enable, and then race namespace teardown against writes to the still-open sysctl file. In the vulnerable kernel, the sysctl handler can reach SCTP per-net state and update the SCTP control socket after that socket has already been released, creating a use-after-free condition. The immediate result may be a kernel oops or panic. A more advanced exploit would attempt to groom kernel memory so the freed object is replaced with attacker-influenced data, potentially turning the memory safety bug into privilege escalation, though no public exploit is indicated by the supplied intelligence.

How to fix it

Update the Linux kernel to a vendor release that includes the SCTP fix for this issue. The fix changes SCTP per-network-namespace sysctl registration so it occurs only after the SCTP control socket is successfully created, unregisters the sysctl table before destroying the control socket, and safely handles missing sysctl registration state during cleanup. If exact package versions are not yet available from the operating system vendor, track the vendor advisory for CVE-2026-68162 and deploy the first kernel update that includes the SCTP netns teardown fix. As interim mitigations, disable or unload SCTP where it is not required, prevent automatic loading of the sctp module, restrict unprivileged user namespace and network namespace creation, limit CAP_NET_ADMIN in containers and sandboxed workloads, and block untrusted workloads from writing /proc/sys/net/sctp/auth_enable. Reboot systems after kernel replacement unless using a vendor-supported live patch that explicitly covers this SCTP change.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes SCTP support, whether the sctp module is loaded, and whether /proc/sys/net/sctp/auth_enable exists. Confirm remediation by verifying the running kernel version matches a vendor-fixed build, not merely that an updated package is installed on disk. On source-based or custom kernels, verify the SCTP initialization and teardown ordering matches the fix: per-net SCTP sysctl registration occurs in the SCTP control-socket initialization path after control socket creation, and sysctl unregistration occurs before control socket destruction. Operational validation can include confirming SCTP is disabled if not required, confirming unprivileged users cannot create network namespaces where policy requires that restriction, and reviewing container runtime profiles to ensure unnecessary CAP_NET_ADMIN access is removed. Avoid destructive proof-of-concept testing on production systems because triggering the bug can crash the kernel.

Typical attack path

1. Obtain local execution on a Linux system, container host, or workload with access to namespace-related system calls.
2. Ensure SCTP support is available or trigger loading of the SCTP kernel module if permitted.
3. Create a new network namespace, often using unshare, clone, or container runtime behavior.
4. Open /proc/sys/net/sctp/auth_enable within the target network namespace and keep the file descriptor open.
5. Tear down the network namespace while retaining or racing access to the opened sysctl file.
6. Write to the SCTP auth_enable sysctl during the vulnerable initialization or teardown window.
7. Trigger a use-after-free in the SCTP sysctl/control-socket path, causing kernel crash or potential memory-corruption behavior.

How to detect it

Look for evidence of attempted triggering through local activity rather than remote network traffic. Useful log sources include auditd, Linux kernel logs, systemd-journald, container runtime logs, Kubernetes audit logs, EDR process telemetry, and shell history where available. Hunt for writes to /proc/sys/net/sctp/auth_enable or sysctl changes to net.sctp.auth_enable, especially when clustered with unshare, ip netns add/delete, container creation/destruction, or repeated namespace churn. Review kernel logs for oops, panic, general protection fault, KASAN, KFENCE, or UBSAN reports that mention SCTP sysctl functions, SCTP control sockets, network namespace cleanup, or use-after-free. Check for unexpected loading of the sctp kernel module on systems that do not normally use SCTP. If a crash occurred, preserve vmcore/kdump artifacts and inspect stack traces for proc_sctp_do_auth, sctp_ctrlsock_exit, sctp_ctrlsock_init, inet_ctl_sock_destroy, or sctp_sysctl_net_unregister. There are no reliable network-only indicators for this flaw because exploitation is local and centered on kernel namespace/sysctl state.

• /proc/sys/net/sctp/auth_enable
• net.sctp.auth_enable
• sysctl -w net.sctp.auth_enable
• proc_sctp_do_auth
• sctp_ctrlsock_init
• sctp_ctrlsock_exit
• sctp_sysctl_net_unregister
• inet_ctl_sock_destroy
• KASAN: use-after-free
• BUG: KASAN: use-after-free in proc_sctp_do_auth
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• modprobe sctp
• insmod sctp
• unshare -n
• ip netns add
• ip netns delete
• CLONE_NEWNET
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems that expose SCTP support, load the sctp module, run container workloads, or permit unprivileged user/network namespace creation.
• Prioritize patching container hosts, multi-user Linux servers, CI/CD runners, Kubernetes nodes, and sandbox platforms where local users or workloads can manipulate network namespaces.
• Apply the vendor kernel update containing the SCTP netns sysctl/control-socket lifecycle fix and reboot into the fixed kernel.
• Where SCTP is not business-required, disable SCTP and prevent sctp module autoloading as a defense-in-depth measure.
• Restrict CAP_NET_ADMIN for containers and untrusted workloads; avoid privileged containers unless strictly necessary.
• Disable or restrict unprivileged user namespaces and network namespaces where compatible with application requirements.
• Add monitoring for writes to /proc/sys/net/sctp/auth_enable, repeated network namespace creation/deletion, SCTP module loading, and kernel crash signatures referencing SCTP sysctl handlers.
• Treat any kernel oops, panic, or KASAN use-after-free involving proc_sctp_do_auth, sctp_ctrlsock, or net.sctp.auth_enable as a high-priority forensic event.
• Track vendor advisories because affected product lists and exact fixed package versions may vary by distribution and kernel branch.