SMC CVE-2026-31507: tee() splice double-free leads to Linux kernel panic

The Linux kernel’s SMC networking stack is back in the security spotlight with CVE-2026-31507, a flaw that can turn a seemingly ordinary tee operation into a double-free and, in practice, a kernel crash. The bug sits in the splice-based receive path, where SMC’s smc_rx_splice attaches private state to a pipe buffer and assumes that state will be released exactly once. But when tee duplicates that pipe buffer, both copies end up sharing the same private pointer, and the second teardown walks straight into freed memory. Public kernel records describe the failure chain as a slab-use-after-free in smc_rx_pipe_buf_release, followed by a NULL-pointer dereference in smc_rx_update_consumer and a fatal kernel panic.

Background​

The relevant subsystem here is SMC, short for Shared Memory Communications, a Linux networking technology designed to let eligible workloads move data with less CPU overhead than conventional TCP paths. In broad terms, SMC tries to combine the familiarity of sockets with the efficiency of shared-memory transport, which makes it attractive in high-throughput enterprise environments. That same design also means SMC has to integrate carefully with the kernel’s buffer-management machinery, especially the splice and pipe APIs that support zero-copy data movement.
The vulnerability exposed by CVE-2026-31507 is not just a garden-variety memory-management slip. It is a reminder that the kernel’s zero-copy plumbing is layered and stateful: a pipe buffer can carry both a page reference and arbitrary per-buffer metadata in pipe_buffer.private. The kernel’s documentation makes clear that tee is specifically the system call that duplicates pipe buffers into another pipe, which means any private state attached to those buffers must be cloned or refcounted correctly. If the metadata is not accounted for, the duplicated buffers may appear independent while secretly sharing the same teardown target.
That is exactly what happened here, according to the CVE record. smc_rx_splice allocates one smc_spd_priv object per pipe_buffer, stores it in pipe_buffer.private, and then relies on a generic pipe-buffer get operation that only increments the page reference count. The problem is that the smc_spd_priv itself is not reference-counted in the path used by tee, so the original and the cloned buffer both believe they own the same state. When each pipe is later closed, both release paths fire against the same object, and the second release becomes a use-after-free.
This bug also lands at an awkward time for the Linux ecosystem because CVE records for kernel issues are increasingly tied to upstream fixes and stable backports. The kernel project’s own CVE policy states that CVEs are assigned after a fix is available and applied to a stable tree, and then tracked by the commit that resolved the issue. That makes the published stable references around CVE-2026-31507 especially important for vendors, distribution maintainers, and enterprise administrators who need to match their kernel builds against corrected upstream commits.
At a practical level, the issue matters because tee is not an exotic call. It is part of the standard splice toolbox used by applications and middleware that want to move data between pipes without copying it into userspace first. That means the bug is conceptually narrow but operationally broad: if a workload can trigger SMC splice reads and duplicate the resulting pipe buffer, it may be able to hit the bad release path without any special privileges beyond the ability to exercise the relevant socket and pipe APIs.

---

What the CVE Actually Describes​

The public description of CVE-2026-31507 centers on a mismatch between page reference handling and private object ownership. The kernel’s generic_pipe_buf_get helper is good enough for a plain page-backed pipe buffer, but it is not enough when the buffer also carries custom metadata that needs its own lifecycle management. In SMC’s case, that metadata is smc_spd_priv, and the reported failure is that the duplication path clones the buffer while leaving the same private pointer attached to both copies.

The Double-Free Path​

The CVE record lays out the sequence plainly. The first release of the pipe buffer calls kfree(priv), drops the socket reference with sock_put(sk), and updates consumer accounting through smc_rx_update_cons. That is fine for the first owner. The second release reaches the same code again, but by then the private object has already been freed, so the teardown path dereferences stale memory and cascades into a crash.
This is the kind of kernel bug that looks small in code and large in impact. A double-free is dangerous on its own because it can corrupt allocator metadata or hand the same slab object back to two different consumers. Here, the impact is even more obvious in the crash trace: the second teardown reaches into priv->smc after priv itself has already been freed, and the kernel trips a slab-use-after-free report before ultimately dereferencing a bad pointer. That means the bug is not merely theoretical; it is reproducible enough to show up under KASAN.

Why tee Matters​

The subtlety is that tee does not duplicate the underlying data in the classic sense. It duplicates the pipe-buffer metadata and shares the same backing pages, which is why the pipe infrastructure needs careful get and release methods. The Linux documentation explicitly notes that tee is the mechanism that duplicates the buffers in one pipe into another, and that the pipe layer expects the buffer operations to preserve lifecycle integrity. SMC’s mistake was to treat its private pointer as though the generic page-level reference was enough.
In other words, the bug is not just a memory bug; it is a semantic bug. Even if a refcount were added to smc_spd_priv, the CVE record notes that consumer-cursor accounting would still be wrong, because smc_rx_update_cons would advance the receive window twice for the same data. That means the issue touches both security and correctness, a combination that often makes kernel fixes more invasive than they first appear.

---

Why the Crash Chain Is So Serious​

The crash trace attached to the CVE is especially concerning because it shows a straightforward path from memory corruption to kernel panic. Once smc_rx_pipe_buf_release runs for the second time, the freed private object is consulted again, and the kernel eventually reaches smc_rx_update_consumer with invalid state. At that point, the failure is no longer confined to one subsystem; it becomes a system-wide reliability problem.

KASAN Is Catching the Right Kind of Bug​

The public report says KASAN reported the slab-use-after-free first, which is useful because it means the kernel’s sanitizers are seeing the memory violation before the corruption spreads further. That is good news for developers, but it also suggests the bug is structurally severe enough to be caught by standard debugging instrumentation. In security terms, a bug that can be turned into a panic is already a denial-of-service issue, and in the wrong circumstances it may become more.
The fact that the panic is triggered during close is another reason operators should pay attention. Resource release paths are often assumed to be mundane, and that makes them a favorite target for reliability bugs. A workload can run for a long time before the bad release sequence is triggered, which means the defect may hide in staging, show up intermittently in production, and then become difficult to root-cause once it begins cascading through the kernel stack. That pattern is familiar, and it is exactly why teardown bugs are so frustrating.

Consumer Accounting Becomes Corrupted​

The CVE text also points to receive-window accounting corruption. smc_rx_update_cons advances the consumer cursor, and that cursor represents how much of the receive buffer the kernel believes has been consumed. If the same data is accounted for twice, the kernel may believe the peer has moved further ahead than it really has, which can destabilize subsequent receive behavior and potentially break protocol expectations.
That matters because it broadens the issue beyond a straightforward memory-safety failure. Even if the double-free were somehow neutralized with a refcounting patch, the semantic mismatch would remain. The problem, then, is not simply “do not free the same thing twice.” It is “do not let duplicated pipe buffers pretend they are independent owners of a single receive cursor.” That is a harder design problem, and it explains why the fix chosen by upstream is to reject those duplication paths outright.

---

The Fix Strategy​

The fix strategy described in the CVE record is blunt but sensible: the .get callback is now treated as incompatible with the relevant duplication scenarios, and both tee(2) and splice_pipe_to_pipe for partial transfers return -EFAULT rather than attempting to duplicate the SMC buffer. That is an intentionally conservative choice. It avoids trying to make a semantically dubious operation safe when the underlying receive logic was never designed for shared duplication.

Why Not Just Add a Refcount?​

A refcount sounds attractive because it would appear to solve the immediate double-free. But the CVE text makes clear that refcounting alone would be incomplete, because the receive-window cursor would still move incorrectly. In kernel security engineering, this is a classic example of why the first plausible patch is not always the right patch. Fixing lifetime bugs without fixing ownership semantics can leave the system consistent in memory but inconsistent in protocol state.
That distinction matters to administrators as well. Some vulnerabilities are patched by hardening allocation and freeing paths, while others are patched by forbidding specific behavior entirely. This one falls into the second category because the operation itself is questionable. The record explicitly says that users who need to duplicate SMC socket data should use a copy-based read path instead. That is an operational constraint, not just an internal code change.

What -EFAULT Means Here​

Returning -EFAULT is a strong signal to user space that the kernel will not support this workflow through the zero-copy path. The practical effect is that applications built around pipe duplication need to handle failure and choose a different strategy, likely one that copies data instead of trying to clone the pipe buffer directly. That may cost performance, but it preserves correctness and avoids the crash path.
This is one of those patches where the answer is not “make it faster” but “make it impossible to misuse.” That approach can feel restrictive, especially in a subsystem built around high-performance data movement, yet it is often the right call when the buffer lifecycle is too complex to safely share. In kernel code, the cheapest duplication is sometimes the most expensive bug.

---

Where This Sits in the Broader SMC Story​

SMC has been a niche but important part of Linux networking for years, especially in environments where memory bandwidth and latency are under constant pressure. Because it lives at the intersection of sockets, shared memory, and special-purpose transport logic, its failure modes tend to be more intricate than those of ordinary TCP code. The CVE record for this issue fits that pattern perfectly: the bug is not in packet parsing or cryptography, but in the glue code that moves data between kernel abstractions.

The Zero-Copy Appeal​

The appeal of splice-based APIs is obvious: they move data inside the kernel without bouncing it through user space. That reduces copies, lowers CPU overhead, and can improve throughput in exactly the kinds of services that care about SMC. But zero-copy paths also increase the burden on kernel developers, because metadata ownership must stay coherent across multiple abstraction layers. The more “direct” the data path becomes, the more fragile the lifecycle rules can be.
That fragility is not unique to SMC, of course. The Linux kernel has seen a steady stream of splice-, pipe-, and page-accounting bugs across many subsystems. What makes this case notable is that SMC adds a private object on top of the usual page buffer, which means the standard helper functions are no longer sufficient. In practice, the vulnerability is a cautionary tale about extending a generic kernel primitive with subsystem-specific state and then assuming the generic helpers will manage that state for free.

Enterprise vs. Consumer Impact​

For enterprise Linux deployments, the concern is not just whether the bug can crash a host, but whether a workload can trigger it under realistic production traffic. Systems using SMC for high-volume back-end workloads may be exactly the kinds of environments where buffer duplication behavior gets exercised indirectly through middleware or observability tooling. That makes rapid patch alignment important.
For consumer systems, the risk is narrower because SMC is not widely used in typical desktop or laptop scenarios. But “narrower” is not the same as “irrelevant.” Any kernel bug that can trigger a panic is a stability problem, and distros often carry kernel features beyond what a user knowingly enabled. That is why kernel advisories matter even when the affected feature sounds specialized.

---

The Technical Lesson for Kernel Developers​

One of the strongest lessons from CVE-2026-31507 is that generic helpers are not a substitute for subsystem ownership models. generic_pipe_buf_get is perfectly fine for what it was designed to do: handle page reference counts in a standard pipe buffer. But it cannot intuit that a subsystem has stashed extra ownership-sensitive state in pipe_buffer.private. Once that private state exists, the subsystem has to define the duplication and release rules explicitly.

Ownership Must Be Explicit​

The kernel’s pipe infrastructure assumes that a buffer’s lifetime can be described with the standard get and release callbacks. The SMC path violated that assumption by binding a private pointer to each buffer without binding an equivalent duplication policy to the pointer itself. That made the original buffer and its tee clone look independent when, in fact, they were sharing a single teardown target.
A developer reading this bug should also notice the asymmetry between data and metadata. The data page may be safely reference-counted, but the metadata that tracks protocol state may not be. That is why the kernel’s pipeline abstractions are powerful but dangerous: they encourage reuse, yet they do not guarantee that the semantics of reused objects remain valid across every transformation. The abstraction is sound; the assumption was not.

Partial Transfers Are Especially Tricky​

The CVE text calls out partial transfers via splice_pipe_to_pipe as well, which is a helpful clue that the dangerous path is not limited to one syscall. Partial movement between pipes can create surprising edge cases because the kernel is not just duplicating a buffer, but potentially splitting or relinking ownership in ways that are hard to reason about. If the private SMC state cannot survive that choreography, the safest answer is to stop the operation early.
That kind of defensive posture is often what separates robust kernel code from code that is merely “working on the happy path.” It is easy to write zero-copy code that works when a single consumer reads a buffer once. It is much harder to preserve correctness when the same buffer is cloned, partially moved, and then released through multiple call chains.

---

Patch Distribution and Stable-Tree Reality​

The CVE record includes multiple stable kernel references, which strongly suggests the fix has been propagated through the kernel’s long-term maintenance machinery. That matters because downstream distributions often ship kernels from stable trees rather than mainline, and enterprise users rarely run upstream tip kernels in production. The difference between a mainline fix and a stable backport is therefore not academic; it is the difference between a patch that exists and a patch that reaches deployed systems.

Why the Commit References Matter​

Kernel CVE entries are frequently tied to commit IDs, and this one is no exception. The NVD record lists several git.kernel.org/stable/c/ references, which are the breadcrumbs security teams use to map a vulnerability to the exact resolved code in stable branches. That is the mechanism by which distro maintainers and security scanners can determine whether a shipped kernel has the fix or still needs remediation.
From an operational perspective, this is where the story becomes concrete. An administrator does not need to understand every detail of SMC internals to know the important questions: Is the kernel version affected? Has the vendor backported the fix? Does the workload even use SMC or pipe duplication paths? Those are the questions that decide whether the issue is a theoretical bug report or an active incident response item.

Vendor Guidance Still Matters​

The Linux kernel security process emphasizes coordination and stable backports for serious bugs, and that is especially relevant here because the flaw combines memory safety and protocol integrity issues. Distribution vendors typically absorb such fixes into their own patch streams, sometimes with additional hardening. That means a public CVE is only the starting point; the real question is when your vendor’s kernel build actually contains the correction.
In practice, this kind of bug is also a good reminder that “published” does not mean “everywhere fixed.” Security teams still need to map version numbers, backport status, and vendor changelogs. For a subsystem as specialized as SMC, that mapping can be especially important because some organizations only discover they are using the feature after they start investigating a related issue.

---

Strengths and Opportunities​

This fix is notable not because it is elegant, but because it is decisive. It chooses safety and semantic clarity over trying to preserve an unsafe zero-copy optimization path, which is often the right tradeoff in the kernel. It also gives operators a clear workaround: use a copy-based path when duplication is needed, and treat pipe-buffer cloning for SMC data as unsupported.

• Eliminates the crash path by preventing the problematic duplication sequence from proceeding.
• Avoids double-free risk without pretending a simple refcount is enough.
• Protects protocol state by stopping incorrect consumer-cursor advancement.
• Clarifies API behavior for user space by returning -EFAULT on unsupported duplication attempts.
• Reduces ambiguity in how SMC splice buffers should be treated across pipes.
• Improves auditability because the failing behavior is now explicit rather than hidden.
• Fits kernel hardening practice by preferring correctness over fragile optimization.

Risks and Concerns​

The downside is that defensive fixes like this can surprise applications that relied on zero-copy duplication and never expected tee to fail. More broadly, the issue highlights how easily a seemingly small metadata mistake in a kernel fast path can become a crash or a state-corruption bug. It also raises the possibility that other subsystems using similar pipe-buffer patterns may need the same kind of scrutiny.

• Application breakage if software assumes tee always works for SMC-derived pipe data.
• Performance loss when workloads must fall back to copy-based reads.
• Hidden dependency risk in middleware that uses splice semantics indirectly.
• Residual correctness issues in code paths that were never designed for cloned ownership.
• Kernel panic exposure if affected systems are left unpatched.
• Potential for related bugs in neighboring subsystems that use custom pipe_buffer.private state.
• Operational blind spots because many teams do not actively inventory SMC usage.

---

Looking Ahead​

The next thing to watch is how quickly vendors backport the fix into enterprise kernels and how clearly they document the behavioral change. A kernel patch that resolves a crash can still cause friction if applications do not understand that tee and partial splice_pipe_to_pipe operations are now expected to fail for this path. That makes release notes and distro advisories especially important for admins and developers who depend on high-throughput networking stacks.
A second area to watch is whether the broader pipe and splice ecosystem gets a deeper review. Bugs like this often reveal a pattern: the kernel’s generic plumbing is safe only so long as every subsystem using it respects the same lifecycle rules. Once private state enters the picture, a single overlooked callback can create a security issue that is both hard to notice and easy to trigger in the right workload.
Finally, watch for downstream vendors to frame this as both a security update and a stability fix. That framing is accurate. The public evidence shows a memory-safety flaw with a kernel panic outcome, but it also shows a deeper design correction: certain SMC splice buffers simply should not be duplicated through the zero-copy path at all.

• Verify whether your kernel includes the stable fix.
• Check whether any workloads use SMC plus splice or tee-driven pipe duplication.
• Plan for copy-based fallbacks where duplication is required.
• Review vendor advisories for backport timing and package versions.
• Monitor for related fixes in other subsystems that use custom pipe-buffer metadata.

CVE-2026-31507 is a good example of the kind of kernel flaw that never looks dramatic in the source tree but can become very dramatic at runtime. It combines a lifetime-management mistake, a protocol-accounting error, and a crash-prone release path into one tidy package of trouble. The immediate fix is to block the bad duplication behavior, but the longer lesson is broader: in kernel code, shared buffers are only safe when every layer agrees on who owns them, who counts them, and who gets to free them.

---

Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center