Description
In the Linux kernel, the following vulnerability has been resolved:

sctp: keep chunk->transport in step with the list it is queued on

__sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's
transmitted list without updating chunk->transport:

if (chunk->tsn_gap_acked) {
list_move_tail(&chunk->transmitted_list,
&transport->transmitted);
continue;
}

The chunk then sits on a live transport's list while chunk->transport still
names a different one. If that transport is removed - sctp_assoc_rm_peer()
from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk
is left with a dangling pointer. sctp_assoc_rm_peer() scrubs
peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on
neither.

The pointer is not followed while tsn_gap_acked is set. A SACK that
reneges on the TSN clears the flag, and the next SACK reaches

tchunk->transport->flight_size -= sctp_data_size(tchunk);

inside the freed transport. KASAN reports a slab-use-after-free read in
sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the
removal and the SACKs come from the association peer.

Set chunk->transport at the move. The ordinary resend path needs nothing:
it reaches its list_move_tail() only after sctp_packet_append_chunk()
returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the
chunk by then.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Published: 2026-08-22
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel SCTP implementation moves a chunk onto another transport’s transmitted list without updating the chunk’s transport pointer, which can leave the chunk pointing to a freed transport object. When a subsequent SACK clears the gap‑acked flag, the code dereferences the dangling pointer, resulting in a slab‑use‑after‑free read and possible exploitation by an attacker to execute arbitrary code at kernel level.

Affected Systems

Linux kernel, all variants that include the SCTP stack. The vulnerability is present in any kernel configuration that builds the SCTP transport module; no specific kernel version is listed.

Risk and Exploitability

EPSS information is not available and the vulnerability is not listed in the CISA KEV catalog. Nevertheless, a use‑after‑free in kernel space can provide local privilege escalation to an attacker with the ability to initiate SCTP traffic. The defect requires the attacker to control an SCTP association that triggers an ASCONF Delete‑IP and subsequently receives a SACK, which may be achievable in environments that allow untrusted SCTP peers.

Generated by OpenCVE AI on August 22, 2026 at 17:22 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest kernel patch that corrects the SCTP chunk transport pointer handling.
  • If SCTP is not needed, compile the kernel without SCTP support or unload the SCTP module.
  • As a temporary measure, block SCTP traffic from untrusted networks via firewall or network segmentation.

Generated by OpenCVE AI on August 22, 2026 at 17:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 17:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Sat, 22 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; } The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches tchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Title sctp: keep chunk->transport in step with the list it is queued on
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-22T15:31:40.466Z

Reserved: 2026-08-15T05:44:03.918Z

Link: CVE-2026-74588

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-22T16:16:30.960

Modified: 2026-08-22T16:16:30.960

Link: CVE-2026-74588

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T18:00:04Z

Weaknesses