CVE-2026-68162 is a use-after-free in the Linux kernel's SCTP implementation where the auth_enable sysctl handler dereferences a control socket pointer that can be freed while the sysctl remains registered. The vulnerability stems from registering sysctls in sctp_defaults_init() while the control socket is created in sctp_ctrlsock_init() — the sysctl table holds a pointer to net->sctp.ctl_sock before that object exists, and the registration outlives the socket on teardown because no ordering constraint connects the two init functions.

The fix (moving sysctl registration after socket creation, unregistering before destruction) is mechanically correct. But the deeper pattern this CVE exposes is the kernel's per-net sysctl infrastructure itself — a registration mechanism that decouples ctl_table creation from the lifecycle of the objects those tables guard. Every network protocol that registers per-net sysctls (IPv6, DCCP, RDS, phonet, ieee802154, and others) operates in the same structural window where proc handlers can dereference net->proto pointers that may have already been freed during namespace destruction.

This isn't an isolated ordering mistake. The kernel's genealogy of similar UAFs — netfilter sysctls, inet_protos, genetlink controller teardown races — shows a pattern where the registration API makes the dangerous ordering structurally attractive: developers register knobs early because the API has no objection, and the enforcement lives in discipline rather than in the interface. The sysctl registration call site looks identical whether the underlying object exists or not, so incorrect ordering survives code review that checks for syntactic correctness but can't see the semantic dependency.

What to check: audit any network protocol that registers sysctls in a separate init function from the objects those sysctls reference. The red flag is a ctl_table handler dereferencing a pointer that lives in a different init phase. On the defensive side, monitor for UAF patterns in network namespace teardown paths where procfs or sysctl handlers may race with socket/struct sock destruction.

The systemic question this CVE raises is whether kernel subsystem APIs should require explicit lifecycle declarations — a registration call that says "this sysctl depends on that object's existence" rather than leaving the dependency implicit. Without that enforcement, each new network protocol developer faces the same locally-rational choice that produced this vulnerability, and code review becomes the only backstop against a pattern the API permits.