Skip to main content

Linux Kernel CVE-2026-63971

| EUVDEUVD-2026-45744 HIGH
2026-07-19 Linux GHSA-p8fw-9cj8-hc3p
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.0 HIGH

Local unprivileged SCTP socket access gives AV:L/PR:L; winning the socket-lock-drop race is timing-sensitive so AC:H; wrong-lock/use-after-free enables full C/I/A impact within the kernel (S:U).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:35 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:55 cve.org
HIGH 7.8
CVE Published
Jul 19, 2026 - 14:55 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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.

AnalysisAI

Local privilege escalation and memory corruption in the Linux kernel SCTP subsystem stems from a race condition where sctp_wait_for_connect() fails to detect that an association was migrated to a new socket via SCTP_SOCKOPT_PEELOFF while the socket lock was released. An attacker with a local account and the ability to open SCTP sockets can race a connecting association against a peeloff getsockopt() call, causing the connect path to operate on asoc->base.sk under the wrong socket lock in sctp_datamsg_from_user(). This is a fixed upstream kernel bug (EUVD-2026-45744) with a vendor patch available; no public exploit is identified at time of analysis and EPSS exploitation probability is low at 0.21% (11th percentile).

Technical ContextAI

The affected component is the SCTP (Stream Control Transmission Protocol) implementation in net/sctp within the Linux kernel. SCTP supports a 'peeloff' operation (getsockopt with SCTP_SOCKOPT_PEELOFF) that detaches a single association from a one-to-many style socket into its own one-to-one socket, reassigning the association's backing socket pointer asoc->base.sk. sctp_wait_for_connect() sleeps until the association reaches ESTABLISHED, and while sleeping it drops and re-acquires the socket lock. The root cause is a classic time-of-check/time-of-use race (CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization), which here can escalate to using stale locking and a dangling/mismatched socket reference (CWE-416 Use-After-Free class behavior) because the function returns success without re-validating that sk still equals asoc->base.sk. The fix mirrors an existing guard in sctp_wait_for_sndbuf() by re-checking sk != asoc->base.sk after waking and returning an error on mismatch. The CPE data (cpe:2.3:a:linux:linux) is generic and does not itself pinpoint versions; the EUVD version ranges are authoritative here.

RemediationAI

Apply the vendor-released patch by upgrading to a fixed stable kernel: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, or 7.1 (or later within your branch), obtained from your distribution or the stable trees at git.kernel.org referenced above (for example https://git.kernel.org/stable/c/bcfeac79af740735ace44008b4a11b8e5add20f5). Where immediate patching is not possible, the most effective compensating control is to reduce local exposure to the SCTP stack: if SCTP is not required, prevent the sctp module from loading by adding an 'install sctp /bin/true' or blacklist entry in modprobe configuration, which fully removes the attack surface but breaks any application relying on SCTP. If SCTP must remain enabled, restrict who can create SCTP sockets and open local shell access, since exploitation requires a local account able to invoke the connect and peeloff paths; note this only narrows, not eliminates, the race. There is no meaningful network-side firewall mitigation because the trigger is local socket API usage, not inbound traffic.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-63971 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy