Katalog CVE

CVE-2025-39723

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

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.21%

Percentyl 12 - wyżej niż 12% wszystkich znanych CVE

Streszczenie

W jądrze Linux w podsystemie netfs wykryto błąd w obsłudze błędów zapisu niebuforowanego. Gdy wszystkie podzadania strumienia zapisu niebuforowanego zakończą się niepowodzeniem, zmienna stream->transferred nie jest aktualizowana i zachowuje początkową wartość LONG_MAX. Prowadzi to do zwrócenia przez funkcję ->write_iter() wartości LONG_MAX zamiast błędu, co może skutkować awarią systemu (oops) podczas próby czyszczenia buforów potoku.

Ocena ryzyka

Organizacja narażona jest na awarię systemu (kernel panic) podczas zapisu plików przez CIFS z wyłączonym buforowaniem, gdy zabraknie miejsca na dysku. Może to prowadzić do utraty danych i przerwania działania usług.

Rekomendacja

Należy niezwłocznie zaktualizować jądro Linux do wersji zawierającej poprawkę (commit z dodaniem flagi ważności stream->transferred i inicjalizacją wartością zero). Dla systemów produkcyjnych zaleca się zastosowanie łatki bezpieczeństwa.

Inne podatności w Linux kernel

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

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix unbuffered write error handling If all the subrequests in an unbuffered write stream fail, the subrequest collector doesn't update the stream->transferred value and it retains its initial LONG_MAX value. Unfortunately, if all active streams fail, then we take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set in wreq->transferred - which is then returned from ->write_iter(). LONG_MAX was chosen as the initial value so that all the streams can be quickly assessed by taking the smallest value of all stream->transferred - but this only works if we've set any of them. Fix this by adding a flag to indicate whether the value in stream->transferred is valid and checking that when we integrate the values. stream->transferred can then be initialised to zero. This was found by running the generic/750 xfstest against cifs with cache=none. It splices data to the target file. Once (if) it has used up all the available scratch space, the writes start failing with ENOSPC. This causes ->write_iter() to fail. However, it was returning wreq->transferred, i.e. LONG_MAX, rather than an error (because it thought the amount transferred was non-zero) and iter_file_splice_write() would then try to clean up that amount of pipe bufferage - leading to an oops when it overran. The kernel log showed: CIFS: VFS: Send error in write = -28 followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008 with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0 or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755) Also put a warning check into splice to announce if ->write_iter() returned that it had written more than it was asked to.

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