Skip to main content
VulnerabilityPublished

CVE-2026-64047: Linux kernel · net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring

Source GCVE Database

0
Authoritative record:CVE-2026-64047· Critical 9.8

Not known to be exploited · CVSS 9.8 Critical · fixed in eca989eab4b2599dcb02f72140a7c08f08838520 : patch Linux kernel as a priority.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 43% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in eca989eab4b2599dcb02f72140a7c08f08838520, 285943c6e7ca309bbea84b253745154241d9788a, 84158c2997159df4a0d70cd9c46774512d32a522 +6
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • >=5.4.14 <5.5
Fixed in
  • eca989eab4b2599dcb02f72140a7c08f08838520
  • 285943c6e7ca309bbea84b253745154241d9788a
  • 84158c2997159df4a0d70cd9c46774512d32a522
  • 73963a375885d5ccb7def39fd0b4f542e0f343dd
  • 66339b71f105e6f83e0da3b9583d95077534fe1d
  • 47110c3a9ac247b688657337f5981efcfcb240dc
  • 131ef12057d92b77b636321b7849c69222405a97
  • 5.5
  • 2fb0dc7e0099686c4e9d2732745d8a31b18c3628
LinuxLinuxAffected
  • =5.5
Fixed in–

AI-suggested

A fix for this vulnerability has been implemented in the Linux kernel source code. Users and administrators should apply the official kernel updates that include this patch. Since this is a kernel-level fix, upgrading to a patched kernel version is the recommended remediation. Patch status is not explicitly confirmed here; check the Linux kernel vendor advisory or distribution security updates for the specific fixed versions.

Description

In the Linux kernel, the following vulnerability has been resolved: net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. */ struct scatterlist data[MAX_MSG_FRAGS + 2]; The current code uses MAX_SKB_FRAGS + 1 as the ring size: sg_chain(&msg_pl->sg.data[msg_pl->sg.start], MAX_SKB_FRAGS - msg_pl->sg.start + 1, msg_pl->sg.data); This places the chain pointer at sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS] instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down") Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).

References

Community reviews

Loading reviews…