Katalog CVE

CVE-2026-31507

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

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.13%

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

Streszczenie

W jądrze Linux w module SMC (Shared Memory Communications) wykryto podwójne zwolnienie pamięci struktury smc_spd_priv podczas duplikowania bufora potoku przez wywołanie tee(). Operator .get dla buforów potoku nie obsługiwał wskaźnika smc_spd_priv, co prowadziło do współdzielenia tego samego obiektu przez oryginalny i sklonowany bufor. Po zwolnieniu obu potoków dochodziło do podwójnego wywołania kfree() na tym samym obiekcie, co skutkowało użyciem po zwolnieniu (UAF) i paniką jądra.

Ocena ryzyka

Atakujący lokalny może doprowadzić do awarii systemu (kernel panic) poprzez wywołanie tee() na gnieździe SMC, co umożliwia eskalację uprawnień lub przerwanie działania usług. Podatność może również powodować uszkodzenie danych w oknie odbiorczym SMC.

Rekomendacja

Należy natychmiast zaktualizować jądro Linux do wersji zawierającej poprawkę (commit w gałęzi net/smc). Jeśli aktualizacja nie jest możliwa, należy ograniczyć dostęp do wywołania tee() dla gniazd SMC poprzez polityki bezpieczeństwa (np. seccomp).

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: net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores the pointer in pipe_buffer.private. The pipe_buf_operations for these buffers used .get = generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv pointer itself was not handled, so after tee() both the original and the cloned pipe_buffer share the same smc_spd_priv *. When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object: 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct] 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF] KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which then escalates to a NULL-pointer dereference and kernel panic via smc_rx_update_consumer() when it chases the freed priv->smc pointer: BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x650 kasan_report+0xc6/0x100 smc_rx_pipe_buf_release+0x78/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smc_rx_update_consumer+0x8d/0x350 Call Trace: <TASK> smc_rx_pipe_buf_release+0x121/0x2a0 free_pipe_info+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64_sys_close+0x4f/0x90 do_syscall_64+0xa6/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smc_spd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately. The .get callback is invoked by both tee(2) and splice_pipe_to_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.

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