Katalog CVE

CVE-2026-52935

WysokieCVSS 7.8
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.12%

Percentyl 2 — wyżej niż 2% wszystkich znanych CVE

Streszczenie

W jądrze Linux w module xfrm/espintcp wykryto podatność polegającą na ponownym wykorzystaniu stanu częściowego wysyłania (ctx->partial) przed jego zakończeniem. Funkcja espintcp_sendmsg() może nadpisać aktywny stan wysyłania, co prowadzi do nieprawidłowego odczytu poza zakresem pamięci.

Ocena ryzyka

Organizacja narażona jest na potencjalny wyciek danych lub awarię systemu z powodu odczytu poza zakresem pamięci podczas przetwarzania ruchu IPsec przez ESP-in-TCP. Może to umożliwić atakującemu zdalne spowodowanie naruszenia poufności lub dostępności usług.

Rekomendacja

Należy niezwłocznie zaktualizować jądro Linux do wersji zawierającej poprawkę (commit usuwający ponowne wykorzystanie ctx->partial). Zaleca się monitorowanie biuletynów bezpieczeństwa dystrybucji i zastosowanie łatki po jej udostępnieniu.

Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS