HIGH
smc Splice Buffer UAF
CVE-2026-31507
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.8HIGH
01Description
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.
02KernelScan AI Analysis
Risk summary
A local attacker with the ability to create SMC sockets can trigger a use-after-free vulnerability by using the tee() system call on SMC splice pipe buffers. This leads to memory corruption that can escalate to kernel panic, potentially causing denial of service or system crashes.
Vulnerability analysis
Root Cause: The SMC splice implementation used generic_pipe_buf_get() which only increments page reference counts when tee(2) duplicates pipe buffers, but doesn't handle the smc_spd_priv pointer stored in pipe_buffer.private. This causes both the original and cloned pipe buffers to share the same smc_spd_priv object, leading to a double-free when both pipes are released.
Attack Surface: Local attack surface requiring the ability to create SMC sockets and use splice/tee system calls. The vulnerability is triggered through normal system call usage patterns involving pipe operations on SMC sockets.
Fix Mechanism: The patch replaces generic_pipe_buf_get with a custom smc_rx_pipe_buf_get() function that returns false, preventing pipe buffer duplication entirely. This eliminates both the double-free vulnerability and the semantic issue of advancing the consumer cursor twice for the same data.
03Fix Versions
| Branch | Fixed in | Patch commit |
|---|---|---|
| 5.10 | 5.10.253 | 7e8916f46c2f |
| 5.15 | 5.15.203 | ae5575e66041 |
| 6.1 | 6.1.168 | 98ba5cb27476 |
| 6.12 | 6.12.80 | 7bcb974c771c |
| 6.18 | 6.18.21 | 54c87a730157 |
| 6.19 | 6.19.11 | 3cc76380fea7 |
| 6.6 | 6.6.131 | 81acbd345d40 |
| mainline | 7.0 | 24dd586bb4cb |