CVE-2026-64564 is a use-after-free in Linux SCTP's ASCONF parameter processing, but calling it a coding error misses the point. The vulnerability is architectural: the kernel caches a transport pointer at the chunk level and reuses it across all parameters in that ASCONF without re-validating when parameters mutate shared transport state. When one DEL-IP parameter frees a transport and a subsequent wildcard DEL-IP in the same chunk operates on that now-invalid pointer, you get the use-after-free. This isn't a forgotten null check—it's a cache abstraction that assumes stability of state the protocol explicitly promises to mutate.
The existing D8 source-address guard (added in an earlier CVE) protects the packet's wire identity, but it doesn't protect the resolved transport that ASCONF processing actually uses. The patch adds a transport-level guard to mirror what D8 does at the source level. That closes this specific exploit chain, but it leaves the underlying caching pattern intact. Any ASCONF parameter sequence where one parameter modifies transport state and a later parameter dereferences the cached transport is a potential replay of this class—ADD-IP with conflicting addresses, SET-PRIMARY followed by operations against the old primary, any multi-parameter mutation of peer state.
What to do: First, verify your kernel version is patched. Second, unless you explicitly use ASCONF/ADDIP (most SCTP deployments do not—RFC 5061 never saw wide deployment), this code path is never exercised and your exposure is minimal. If you do enable ADDIP, audit your ASCONF handling for any multi-parameter sequences and consider whether your association lifecycle could leave dangling transport pointers in primary_path or other cached state. Monitor for any kernel oops references to sctpasconf* functions in production traffic. The deeper architectural question—whether SCTP should use per-parameter transport resolution instead of chunk-level caching—is a design discussion for maintainers, not an immediate operational concern.