Skip to main content

Linux Kernel CVE-2026-64046

| EUVDEUVD-2026-45619 CRITICAL
2026-07-19 Linux GHSA-3mwm-pxvj-5v4x
Critical
Disputed · 9.8 Vendor: Linux
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY
9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.3 MEDIUM

kTLS send path is reachable only by a local socket-using process (AV:L, PR:L), the end==0/start!=0 edge state makes it AC:H, and impact is limited memory leak (C:L) plus likely crash (A:H).

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

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 17:05 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
9.8 (CRITICAL)
Patch available
Jul 19, 2026 - 17:03 EUVD
CVE Published
Jul 19, 2026 - 15:39 cve.org
CRITICAL 9.8
CVE Published
Jul 19, 2026 - 15:39 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

AnalysisAI

Malformed scatterlist chaining in the Linux kernel TLS (kTLS) plaintext send path can hand illegal 'chain-after-chain' input to the crypto subsystem when the ring's end index is 0 while start is non-zero, because the sg_next iterator does not recursively resolve consecutive chain links. This affects the kernel's in-kernel TLS offload used by processes with TLS sockets, and is tagged as an information-disclosure issue. It is not in CISA KEV and no public exploit has been identified; EPSS is low at 0.18% (7th percentile), and a fix is available across multiple stable kernel branches.

Technical ContextAI

The flaw lives in net/tls, the Linux kernel's in-kernel TLS (kTLS) implementation, specifically in how the plaintext scatterlist (SG) ring is chained before being passed to the crypto API for record encryption. Scatterlists use special 'chain' entries to link segments; the kernel's sg_next iterator follows a single chain link but does NOT recursively resolve a chain entry that itself points to another chain entry. When end 0 (nothing was pushed after the wrap slot) but start != 0, the pre-fix code still inserted a wrap chain link that pointed directly at the content-type chain link, producing a chain-after-chain structure that is illegal input to crypto. The upstream fix skips the unnecessary wrap chaining when end 0 (letting TLS 1.3 reuse the wrap slot for its own chaining) and reorders the wrap chaining before the END marker. No CWE was assigned (CWE: N/A), but the root cause is a data-structure/API-contract violation in memory descriptor handling that produces malformed crypto input.

RemediationAI

Vendor-released patch: upgrade to a fixed stable release for your branch - 5.10.258, 5.15.209, 6.1.175, 6.6.142, 6.12.92, 6.18.34, 7.0.11, or 7.1 (or later) - using the corresponding fix commits published at https://git.kernel.org/stable/c/ (e.g., 49a5faaa471ddcd37b6893970c9916eb836e7c31 and the branch-matched siblings). Apply your distribution's kernel update once it incorporates these commits and reboot. If immediate patching is not possible and you need a compensating control, the exposure is limited to the in-kernel TLS path, so you can avoid kTLS by disabling the tls module/offload (do not load net/tls or disable TLS_DEVICE/TLS_SW usage in affected services) and instead terminate TLS in userspace libraries; the trade-off is loss of kTLS performance/offload benefits for those workloads. Restricting which local users/containers can open kTLS sockets reduces reachable attack surface. Verify the fix landed by confirming your running kernel version is at or above the branch-specific fixed release above; do not rely on version strings alone if you carry backported patches.

Vendor StatusVendor

SUSE

Severity: Critical
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-64046 vulnerability details – vuln.today

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