Answer in brief
CVE-2026-64047 records a Unknown severity vulnerability in net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-64047 records a Unknown severity vulnerability in net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <73963a375885d5ccb7def39fd0b4f542e0f343dd || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <47110c3a9ac247b688657337f5981efcfcb240dc || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <84158c2997159df4a0d70cd9c46774512d32a522 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <131ef12057d92b77b636321b7849c69222405a97 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <66339b71f105e6f83e0da3b9583d95077534fe1d || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <eca989eab4b2599dcb02f72140a7c08f08838520 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <2fb0dc7e0099686c4e9d2732745d8a31b18c3628 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <285943c6e7ca309bbea84b253745154241d9788a || d529d6c9f7e3aaeac13c4948f79799ccb825f29d || >=5.4.14 <5.5 | 73963a375885d5ccb7def39fd0b4f542e0f343dd, 47110c3a9ac247b688657337f5981efcfcb240dc, 84158c2997159df4a0d70cd9c46774512d32a522, 131ef12057d92b77b636321b7849c69222405a97, 66339b71f105e6f83e0da3b9583d95077534fe1d, eca989eab4b2599dcb02f72140a7c08f08838520, 2fb0dc7e0099686c4e9d2732745d8a31b18c3628, 285943c6e7ca309bbea84b253745154241d9788a, 5.5 |
| Linux/Linuxgeneric | 5.5 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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).
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <73963a375885d5ccb7def39fd0b4f542e0f343dd || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <47110c3a9ac247b688657337f5981efcfcb240dc || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <84158c2997159df4a0d70cd9c46774512d32a522 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <131ef12057d92b77b636321b7849c69222405a97 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <66339b71f105e6f83e0da3b9583d95077534fe1d || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <eca989eab4b2599dcb02f72140a7c08f08838520 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <2fb0dc7e0099686c4e9d2732745d8a31b18c3628 || >=9aaaa56845a06aeabdd597cbe19492dc01f281ec <285943c6e7ca309bbea84b253745154241d9788a || d529d6c9f7e3aaeac13c4948f79799ccb825f29d || >=5.4.14 <5.5 | 73963a375885d5ccb7def39fd0b4f542e0f343dd, 47110c3a9ac247b688657337f5981efcfcb240dc, 84158c2997159df4a0d70cd9c46774512d32a522, 131ef12057d92b77b636321b7849c69222405a97, 66339b71f105e6f83e0da3b9583d95077534fe1d, eca989eab4b2599dcb02f72140a7c08f08838520, 2fb0dc7e0099686c4e9d2732745d8a31b18c3628, 285943c6e7ca309bbea84b253745154241d9788a, 5.5 |
| Linux/Linuxgeneric | 5.5 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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).
Quoted source text, attributed separately from HOL analysis.