Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2022-50838

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
30/12/2025
Última modificación:
30/12/2025

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stream: purge sk_error_queue in sk_stream_kill_queues()<br /> <br /> Changheon Lee reported TCP socket leaks, with a nice repro.<br /> <br /> It seems we leak TCP sockets with the following sequence:<br /> <br /> 1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.<br /> <br /> Each ACK will cook an skb put in error queue, from __skb_tstamp_tx().<br /> __skb_tstamp_tx() is using skb_clone(), unless<br /> SOF_TIMESTAMPING_OPT_TSONLY was also requested.<br /> <br /> 2) If the application is also using MSG_ZEROCOPY, then we put in the<br /> error queue cloned skbs that had a struct ubuf_info attached to them.<br /> <br /> Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc()<br /> does a sock_hold().<br /> <br /> As long as the cloned skbs are still in sk_error_queue,<br /> socket refcount is kept elevated.<br /> <br /> 3) Application closes the socket, while error queue is not empty.<br /> <br /> Since tcp_close() no longer purges the socket error queue,<br /> we might end up with a TCP socket with at least one skb in<br /> error queue keeping the socket alive forever.<br /> <br /> This bug can be (ab)used to consume all kernel memory<br /> and freeze the host.<br /> <br /> We need to purge the error queue, with proper synchronization<br /> against concurrent writers.

Impacto