CVE-2026-31507
Received Received - Intake
Use-After-Free in Linux Kernel SMC Splice Buffer Causes Kernel Panic

Publication date: 2026-04-22

Last updated on: 2026-04-28

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-28
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 15 associated CPEs
Vendor Product Version / Range
linux linux_kernel 4.18
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 5.11 (inc) to 5.15.203 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.168 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.21 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.11 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.131 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.80 (exc)
linux linux_kernel From 4.18.1 (inc) to 5.10.253 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-415 The product calls free() twice on the same memory address.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's SMC (Shared Memory Communications) splice buffer handling. Specifically, when the tee() system call duplicates a splice pipe buffer, the smc_spd_priv pointer associated with the buffer is not properly managed, leading to both the original and duplicated buffers sharing the same pointer.

When both buffers are released, the kernel attempts to free the same smc_spd_priv object twice, causing a double-free error. This results in a use-after-free condition detected by KASAN, which can escalate to a NULL-pointer dereference and cause a kernel panic (system crash).

Additionally, duplicating an SMC splice buffer causes semantic issues with receive-window accounting, as the consumer cursor is advanced twice for the same data, corrupting internal state.

The fix involves preventing duplication of SMC splice buffers via tee() and splice_pipe_to_pipe(), which now return errors, requiring users to use copy-based read paths instead.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic, leading to a system crash and denial of service. The double-free and use-after-free conditions can destabilize the kernel, potentially interrupting normal operations.

Because the kernel crashes, any services or applications relying on the affected Linux kernel could be unexpectedly terminated, causing downtime and potential data loss.

Furthermore, the corruption of receive-window accounting could lead to unpredictable behavior in network communication using SMC sockets.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a double-free and use-after-free in the Linux kernel's SMC splice buffer handling, which can lead to kernel panics. Detection would typically involve monitoring kernel logs for related error messages.

  • Check kernel logs (e.g., using dmesg) for messages like 'KASAN: slab-use-after-free in smc_rx_pipe_buf_release' or 'kernel NULL pointer dereference' related to smc_rx_update_consumer.
  • Use commands such as `dmesg | grep -i smc_rx_pipe_buf_release` or `journalctl -k | grep -i smc` to find relevant kernel error messages.
  • Monitor for kernel panics or crashes that mention the SMC splice buffer or related functions.

What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, the affected Linux kernel should be updated to a version where the issue is fixed.

Users should avoid duplicating SMC socket data using tee(2) or splice_pipe_to_pipe(), as these operations will now return errors (-EFAULT). Instead, use a copy-based read path for duplicating SMC socket data.

Monitoring and applying kernel patches that address the double-free and use-after-free in smc_rx_pipe_buf_release is critical to prevent kernel panics and potential system instability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart