The vulnerability arises from improper handling of SCTP transmission chunks in the Linux kernel. When a gap‑acked transmission is moved onto a different transport’s transmitted list, the chunk’s transport pointer is not updated. If that transport is later freed—such as during an ASCONF Delete‑IP—the chunk remains with a dangling pointer. Subsequent SACK handling clears the gap‑acked flag and dereferences the now‑invalid pointer, resulting in a slab‑use‑after‑free read. The flaw is a use‑after‑free of a kernel resource (CWE‑825) and, if exploited, could allow an attacker to execute arbitrary code with kernel privileges. Based on the description, it is inferred that an attacker must be able to initiate or influence an SCTP session to trigger the needed conditions, such as sending crafted SCTP packets containing a gap‑acked chunk.

Linux kernel implementations that include the SCTP stack are affected. The vulnerability exists in any kernel configuration that builds the SCTP transport module; the advisory does not specify a kernel version, so all currently shipped kernels with active SCTP support are at risk unless updated. Systems running newer patched kernels after the fix are not vulnerable.

The CVSS score of 9.8 indicates high severity, but the EPSS score of < 1% suggests a low probability that this flaw will be actively exploited. The flaw is not listed in the CISA KEV catalog, further indicating that no zero‑day exploitation has been observed. Attackers would need to control an SCTP peer or otherwise inject specially crafted SCTP packets that trigger the gap‑acked and ASCONF Delete‑IP sequence. While this could be feasible in environments where untrusted SCTP traffic is accepted, the attack surface is limited by the requirement to manipulate SCTP associations. The likely attack vector is therefore inferred to be Remote SCTP traffic from an untrusted network, though local privilege escalation through an already authenticated user with SCTP capabilities is also possible.