CVE-2026-31507

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