In the Linux kernel, the following vulnerability has been resolved: sctp: fix race between sctp_wait_for_connect and peeloff sctp_wait_for_connect()… (CVE-2026-63971)
In the Linux kernel, the following vulnerability has been resolved: sctp: fix race between sctp_wait_for_connect and peeloff sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctp_datamsg_from_user(). Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf() already has, returning an error if the association was migrated while we slept.
AI Analysis
Technical Summary
The vulnerability in the Linux kernel SCTP subsystem involves a race condition between sctp_wait_for_connect() and the peeloff operation. sctp_wait_for_connect() temporarily releases the socket lock while waiting for the SCTP association to reach the ESTABLISHED state. If another thread performs a peeloff operation during this window, the association's socket pointer changes. Upon re-acquiring the old socket lock, sctp_wait_for_connect() does not detect this migration and returns success, causing subsequent code to access the association under an incorrect lock. The patch adds a check comparing the socket pointer before and after waiting, returning an error if a migration is detected, preventing incorrect lock usage.
Potential Impact
If exploited, this race condition could cause kernel code to access SCTP association data structures under the wrong socket lock, potentially leading to data corruption or instability in the kernel's SCTP networking stack. No known exploits are reported in the wild. The impact is limited to SCTP usage in the Linux kernel and requires concurrent operations involving peeloff and connection establishment.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel source code. Users should apply the official kernel updates that include this patch once available. Patch status is not yet confirmed in the provided data; check the Linux kernel vendor advisory or distribution security advisories for the current remediation status and updated kernel versions.
In the Linux kernel, the following vulnerability has been resolved: sctp: fix race between sctp_wait_for_connect and peeloff sctp_wait_for_connect()… (CVE-2026-63971)
Description
In the Linux kernel, the following vulnerability has been resolved: sctp: fix race between sctp_wait_for_connect and peeloff sctp_wait_for_connect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTP_SOCKOPT_PEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctp_wait_for_connect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctp_datamsg_from_user(). Add the same sk != asoc->base.sk check that sctp_wait_for_sndbuf() already has, returning an error if the association was migrated while we slept.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in the Linux kernel SCTP subsystem involves a race condition between sctp_wait_for_connect() and the peeloff operation. sctp_wait_for_connect() temporarily releases the socket lock while waiting for the SCTP association to reach the ESTABLISHED state. If another thread performs a peeloff operation during this window, the association's socket pointer changes. Upon re-acquiring the old socket lock, sctp_wait_for_connect() does not detect this migration and returns success, causing subsequent code to access the association under an incorrect lock. The patch adds a check comparing the socket pointer before and after waiting, returning an error if a migration is detected, preventing incorrect lock usage.
Potential Impact
If exploited, this race condition could cause kernel code to access SCTP association data structures under the wrong socket lock, potentially leading to data corruption or instability in the kernel's SCTP networking stack. No known exploits are reported in the wild. The impact is limited to SCTP usage in the Linux kernel and requires concurrent operations involving peeloff and connection establishment.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel source code. Users should apply the official kernel updates that include this patch once available. Patch status is not yet confirmed in the provided data; check the Linux kernel vendor advisory or distribution security advisories for the current remediation status and updated kernel versions.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-p8fw-9cj8-hc3p
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63971"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912dbdf
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:01:00 UTC
Last updated: 07/20/2026, 21:51:39 UTC
Views: 15
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.