// For flags

CVE-2023-52767

tls: fix NULL deref on tls_sw_splice_eof() with empty record

Severity Score

5.5
*CVSS v3

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved: tls: fix NULL deref on tls_sw_splice_eof() with empty record syzkaller discovered that if tls_sw_splice_eof() is executed as part of
sendfile() when the plaintext/ciphertext sk_msg are empty, the send path
gets confused because the empty ciphertext buffer does not have enough
space for the encryption overhead. This causes tls_push_record() to go on
the `split = true` path (which is only supposed to be used when interacting
with an attached BPF program), and then get further confused and hit the
tls_merge_open_record() path, which then assumes that there must be at
least one populated buffer element, leading to a NULL deref. It is possible to have empty plaintext/ciphertext buffers if we previously
bailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path.
tls_sw_push_pending_record() already handles this case correctly; let's do
the same check in tls_sw_splice_eof().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: corrige NULL deref en tls_sw_splice_eof() con registro vacío syzkaller descubrió que si tls_sw_splice_eof() se ejecuta como parte de sendfile() cuando el texto plano/texto cifrado sk_msg está vacío, el envío La ruta se confunde porque el búfer de texto cifrado vacío no tiene suficiente espacio para la sobrecarga de cifrado. Esto hace que tls_push_record() vaya a la ruta `split = true` (que se supone que solo debe usarse al interactuar con un programa BPF adjunto), y luego se confunda aún más y acceda a la ruta tls_merge_open_record(), que luego supone que hay debe haber al menos un elemento de búfer poblado, lo que lleva a una deref NULL. Es posible tener buffers de texto plano/texto cifrado vacíos si previamente salimos de tls_sw_sendmsg_locked() a través de la ruta tls_trim_both_msgs(). tls_sw_push_pending_record() ya maneja este caso correctamente; hagamos la misma verificación en tls_sw_splice_eof().

In the Linux kernel, the following vulnerability has been resolved: tls: fix NULL deref on tls_sw_splice_eof() with empty record syzkaller discovered that if tls_sw_splice_eof() is executed as part of sendfile() when the plaintext/ciphertext sk_msg are empty, the send path gets confused because the empty ciphertext buffer does not have enough space for the encryption overhead. This causes tls_push_record() to go on the `split = true` path (which is only supposed to be used when interacting with an attached BPF program), and then get further confused and hit the tls_merge_open_record() path, which then assumes that there must be at least one populated buffer element, leading to a NULL deref. It is possible to have empty plaintext/ciphertext buffers if we previously bailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path. tls_sw_push_pending_record() already handles this case correctly; let's do the same check in tls_sw_splice_eof().

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
Attack Vector
Local
Attack Complexity
Low
Authentication
Single
Confidentiality
None
Integrity
None
Availability
Complete
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-21 CVE Reserved
  • 2024-05-21 CVE Published
  • 2025-05-04 CVE Updated
  • 2025-06-29 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.5 < 6.6.4
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.6.4"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.5 < 6.7
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.5 < 6.7"
en
Affected