CVE-2026-31507: Linux Kernel Use-After-Free Vulnerability

CVE-2026-31507 Overview

CVE-2026-31507 is a double-free vulnerability in the Linux kernel's SMC (Shared Memory Communications) networking subsystem. The flaw exists in the smc_rx_splice() function which allocates one smc_spd_priv structure per pipe_buffer and stores the pointer in pipe_buffer.private. When the tee(2) system call duplicates a splice pipe buffer, the generic_pipe_buf_get callback only increments the page reference count without properly handling the smc_spd_priv pointer, resulting in both the original and cloned pipe_buffer sharing the same smc_spd_priv pointer.

When both pipes are subsequently released, smc_rx_pipe_buf_release() is called twice against the same object, leading to a use-after-free condition that can escalate to a NULL pointer dereference and kernel panic.

Critical Impact

This vulnerability can cause kernel panics through NULL pointer dereferences and may potentially allow local privilege escalation through memory corruption in the SMC networking subsystem.

Affected Products

• Linux kernel with SMC (Shared Memory Communications) support enabled
• Systems using tee(2) or splice_pipe_to_pipe() operations with SMC sockets
• Multiple kernel versions across various stable branches

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-31507 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-31507

Vulnerability Analysis

This double-free vulnerability occurs in the Linux kernel's SMC networking implementation when handling splice pipe buffers. The smc_rx_splice() function creates smc_spd_priv structures to track SMC-specific metadata for each pipe buffer. However, the pipe buffer operations incorrectly use generic_pipe_buf_get as the .get callback, which only handles page reference counting and does not account for the privately allocated smc_spd_priv structure.

When a user-space application calls tee(2) to duplicate a pipe buffer, the kernel creates a copy that points to the same smc_spd_priv object without incrementing any reference count on that structure. This creates a situation where two pipe buffers reference the same smc_spd_priv pointer.

The vulnerability manifests during cleanup when both pipes are closed. The smc_rx_pipe_buf_release() function is invoked for each pipe buffer, performing the following operations:

1. First call: kfree(priv) → sock_put(sk) → smc_rx_update_cons() (correct)
2. Second call: kfree(priv) → sock_put(sk) → smc_rx_update_cons() (use-after-free)

The second call operates on already-freed memory, causing KASAN to report a slab-use-after-free in smc_rx_pipe_buf_release(). Subsequently, smc_rx_update_consumer() attempts to dereference the freed priv->smc pointer, triggering a NULL pointer dereference and kernel panic.

Beyond the memory safety issue, duplicating an SMC splice buffer is semantically problematic because smc_rx_update_cons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting.

Root Cause

The root cause is improper reference counting in the SMC splice buffer implementation. The .get callback for SMC pipe buffers used generic_pipe_buf_get, which only increments the page reference count when tee(2) duplicates a buffer. The smc_spd_priv pointer stored in pipe_buffer.private was not properly reference-counted or duplicated, leading to shared ownership without proper lifetime management.

The kernel developers determined that implementing a reference count on smc_spd_priv would fix the double-free but would still leave the cursor-accounting issue unaddressed. The fix instead returns -EFAULT for tee(2) and splice_pipe_to_pipe() operations on SMC splice buffers.

Attack Vector

A local attacker with the ability to create SMC sockets and use the tee(2) system call can trigger this vulnerability. The attack sequence involves:

1. Creating an SMC socket and setting up splice operations with smc_rx_splice()
2. Calling tee(2) to duplicate the splice pipe buffer, creating a second reference to the same smc_spd_priv structure
3. Closing both pipes to trigger the double-free condition
4. Observing kernel panic via NULL pointer dereference in smc_rx_update_consumer()

The vulnerability is triggered through normal system call interfaces and does not require elevated privileges beyond the ability to create SMC sockets and use pipe operations.

Detection Methods for CVE-2026-31507

Indicators of Compromise

• KASAN reports showing "slab-use-after-free in smc_rx_pipe_buf_release" in kernel logs
• Kernel panic messages with "BUG: kernel NULL pointer dereference" at address 0000000000000020
• Stack traces containing smc_rx_update_consumer, free_pipe_info, and pipe_release function calls
• Unexpected kernel crashes on systems using SMC networking with splice operations

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) in debug builds to detect use-after-free conditions early
• Monitor kernel logs for SMC-related crash signatures, particularly in smc_rx_pipe_buf_release() and smc_rx_update_consumer() functions
• Implement audit rules to log tee(2) system calls in conjunction with SMC socket file descriptors
• Deploy kernel crash analysis tools to identify patterns consistent with this double-free vulnerability

Monitoring Recommendations

• Configure kernel crash dump collection to capture memory state when NULL pointer dereferences occur in SMC subsystem
• Monitor for unusual patterns of tee(2) system calls targeting pipe file descriptors associated with SMC sockets
• Review dmesg output regularly for KASAN warnings related to smc_spd_priv allocations
• Implement real-time kernel event monitoring using eBPF probes on smc_rx_splice() and related functions

How to Mitigate CVE-2026-31507

Immediate Actions Required

• Apply the kernel patches from the stable kernel branches immediately on systems using SMC networking
• Audit applications using SMC sockets to identify any that rely on tee(2) with SMC splice buffers
• Consider disabling SMC protocol temporarily on critical systems until patches can be applied
• Restrict access to SMC socket creation through network namespace isolation or seccomp filters

Patch Information

The Linux kernel maintainers have released fixes across multiple stable kernel branches. The patches modify the SMC splice buffer handling to return -EFAULT when tee(2) or splice_pipe_to_pipe() attempts to duplicate SMC splice buffers. Users who need to duplicate SMC socket data must use a copy-based read path instead.

Patches are available from the following kernel commits:

• Commit 24dd586bb4cb
• Commit 3cc76380fea7
• Commit 54c87a730157
• Commit 7bcb974c771c
• Commit 7e8916f46c2f
• Commit 81acbd345d40
• Commit 98ba5cb27476
• Commit ae5575e66041

Workarounds

• Modify applications to use copy-based read paths instead of tee(2) for duplicating SMC socket data
• Implement application-level restrictions to prevent tee(2) calls on SMC splice buffers
• Use network namespace isolation to limit access to SMC sockets on untrusted systems
• Consider using alternative transport protocols (TCP/IP) on systems where SMC security cannot be guaranteed until patching is complete