Skip to main content
VulnerabilityPublished Updated

CVE-2026-64047: Linux kernel · Integer Underflow

Affects Linux kernelSource CVE Database V5

0

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

Data as of 26 Oct 2026, 15:59 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.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers can reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

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–

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…