CVE-2026-31507

What it actually does

This is a local Linux kernel memory-corruption flaw in the SMC networking splice receive path. When SMC socket data is placed into a pipe buffer and that buffer is duplicated with tee(2) or related pipe-to-pipe splice behavior, the duplicated pipe buffers can share the same smc_spd_priv private object. When both buffers are later released, the kernel frees and reuses the same object twice, producing a double-free/use-after-free condition. Observed failure modes include KASAN slab-use-after-free reports, NULL-pointer dereference in smc_rx_update_consumer(), corrupted SMC receive-window accounting, and kernel panic. Because the bug is in kernel memory management and is reachable by a local user able to exercise SMC sockets and pipe splice/tee operations, the impact can extend beyond denial of service to potential local privilege escalation depending on allocator state, hardening, and exploitability on the target kernel build.

Why it matters to the business

A local user or compromised workload could crash affected Linux systems and potentially gain elevated privileges by abusing a kernel memory-safety flaw. For organizations running multi-user Linux hosts, container platforms, build systems, HPC clusters, or shared application servers, this creates risk of service interruption and possible host compromise from an already-local foothold. The issue is not currently listed in CISA KEV, has very low EPSS, no reported exploit maturity in the supplied data, and stable EPSS trend, so it is less urgent than actively exploited internet-facing vulnerabilities; however, kernel memory-corruption flaws should still be prioritized on shared or high-availability Linux systems.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system, such as a shell, compromised service account, malicious container workload with sufficient kernel syscall access, or another low-privileged foothold. The attacker creates or uses an SMC socket and receives data through the SMC splice path so the kernel allocates an smc_spd_priv object and stores it in a pipe_buffer. The attacker then duplicates the pipe buffer using tee(2) or an equivalent pipe-to-pipe splice path. Because the vulnerable pipe buffer get operation only increments the page reference and does not correctly handle the SMC private object, both pipe buffers reference the same smc_spd_priv pointer. When the pipes are closed or released, smc_rx_pipe_buf_release() runs twice on the same object, causing a double free and use-after-free. In the simplest case this crashes the kernel. A more advanced exploit would attempt to shape heap allocations around the freed object and reuse the dangling pointer to corrupt kernel state or execute with elevated privileges, although no public exploit or active exploitation is indicated by the supplied data.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that contains the net/smc fix for the pipe buffer duplication handling. Because no exact fixed package versions were supplied, remediation should be based on vendor advisories for the installed distribution and kernel stream. Reboot into the patched kernel after installation and remove or decommission older vulnerable kernels where operationally feasible. If patching must be delayed and SMC is not required, reduce exposure by disabling or preventing use of the SMC kernel module/protocol where possible, such as blacklisting the smc module or using vendor-supported kernel/module controls. On systems where SMC is built into the kernel, module blacklisting will not be sufficient. As compensating controls, restrict untrusted local code execution, harden container isolation, limit interactive shell access, and monitor for unusual tee/splice activity involving SMC sockets. Applications that need to duplicate SMC socket data should use a copy-based read path rather than duplicating SMC splice buffers.

How to confirm the fix worked

Confirm the host is running a vendor kernel build that includes the net/smc fix, not merely that the package was installed. Validate with the distribution package manager, vendor advisory metadata, and the active kernel reported by uname -r after reboot. Check whether SMC is present or loaded using lsmod, /proc/modules, kernel configuration, or distribution-specific module inventory. If using a mitigation, verify the smc module cannot be loaded and that SMC functionality is not available to untrusted workloads. Functional validation for patched kernels can include a controlled, non-production regression test that attempts to duplicate SMC splice pipe buffers and confirms the operation fails safely, such as returning -EFAULT, without KASAN warnings, NULL-pointer dereferences, or kernel panic. Review kernel logs after validation for smc_rx_pipe_buf_release, smc_rx_update_consumer, KASAN, or kernel oops messages.

Typical attack path

1. Obtain local execution on an affected Linux host.
2. Create or access an SMC socket path that can receive data through smc_rx_splice().
3. Move SMC socket data into a pipe buffer using splice-related operations.
4. Duplicate the pipe buffer with tee(2) or pipe-to-pipe splice behavior.
5. Close or release both pipe instances so smc_rx_pipe_buf_release() is invoked twice for the same smc_spd_priv object.
6. Trigger kernel use-after-free/double-free behavior, resulting in kernel panic or, with additional heap manipulation, possible privilege escalation.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, and panic/oops records. Primary sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg archives, kdump/vmcore metadata, hypervisor console logs, and EDR telemetry that captures Linux kernel oops events. Search for KASAN slab-use-after-free reports or NULL-pointer dereferences involving smc_rx_pipe_buf_release(), smc_rx_update_consumer(), smc_rx_update_cons(), pipe_release(), free_pipe_info(), or processes repeatedly invoking tee/splice behavior around SMC socket activity. If auditd, eBPF, syscall tracing, or EDR telemetry is available, review suspicious local processes that create AF_SMC sockets and then call splice(2), tee(2), or pipe-to-pipe splice operations shortly before a kernel oops, panic, reboot, or service outage. Because the known observable behavior is a kernel crash and no actor-specific indicators are supplied, detection should focus on crash signatures and suspicious local syscall sequences rather than network IOCs.

• BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release
• slab-use-after-free in smc_rx_pipe_buf_release
• BUG: kernel NULL pointer dereference, address: 0000000000000020
• RIP: 0010:smc_rx_update_consumer
• smc_rx_update_consumer+0x8d/0x350
• smc_rx_pipe_buf_release+0x78/0x2a0
• smc_rx_pipe_buf_release+0x121/0x2a0
• Kernel panic - not syncing: Fatal exception
• smc_splice_tee_
• free_pipe_info+0xd4/0x130
• pipe_release+0x142/0x160
• smc_rx_update_cons
• smc_spd_priv

What your security team should do

• Inventory Linux systems that have SMC support enabled or the smc module available, prioritizing shared, multi-tenant, container-hosting, and externally managed compute environments.
• Patch affected Linux kernels through the relevant OS vendor channel and reboot into the fixed kernel during the next appropriate maintenance window; accelerate for shared systems where untrusted local code can run.
• If SMC is unused, disable or blacklist the smc module using supported controls and verify the mitigation is effective after reboot.
• Restrict local code execution from untrusted users and review container runtime policies that allow broad syscall access, especially tee(2), splice(2), and related pipe operations.
• Add kernel-log detection for the SMC-specific crash signatures and investigate any historical KASAN, oops, or panic events involving smc_rx_pipe_buf_release or smc_rx_update_consumer.
• Retain crash dumps, vmcore files, and kernel logs for any matching incidents so responders can distinguish accidental instability from attempted exploitation.
• Track vendor advisories for exact fixed package versions because fixed versions were not supplied in the source data.