net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.5, 5.10.258, 5.15.209, 6.1.175, 6.6.142, and 3 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: total
Summary
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).
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 73963a375885d5ccb7def39fd0b4f542e0f343dd; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 47110c3a9ac247b688657337f5981efcfcb240dc; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 84158c2997159df4a0d70cd9c46774512d32a522; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 131ef12057d92b77b636321b7849c69222405a97; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 66339b71f105e6f83e0da3b9583d95077534fe1d; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in eca989eab4b2599dcb02f72140a7c08f08838520; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 2fb0dc7e0099686c4e9d2732745d8a31b18c3628; From 9aaaa56845a06aeabdd597cbe19492dc01f281ec · fixed in 285943c6e7ca309bbea84b253745154241d9788a; From 5.4.14 · fixed in 5.5
- Linux Linux
5.5
- KernelLinux
From 5.5.0 · fixed in 5.10.258; From 5.11.0 · fixed in 5.15.209; From 5.16.0 · fixed in 6.1.175; From 6.2.0 · fixed in 6.6.142; From 6.7.0 · fixed in 6.12.92; From 6.13.0 · fixed in 6.18.34; From 6.19.0 · fixed in 7.0.11
References 8
git.kernel.org
- stable/c/73963a375885d5ccb7def39fd0b4f542e0f343dd
- stable/c/47110c3a9ac247b688657337f5981efcfcb240dc
- stable/c/84158c2997159df4a0d70cd9c46774512d32a522
- stable/c/131ef12057d92b77b636321b7849c69222405a97
- stable/c/66339b71f105e6f83e0da3b9583d95077534fe1d
- stable/c/eca989eab4b2599dcb02f72140a7c08f08838520
- stable/c/2fb0dc7e0099686c4e9d2732745d8a31b18c3628
- stable/c/285943c6e7ca309bbea84b253745154241d9788a