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

In the Linux kernel, CVE-2026-31507 exposes a deceptively small-looking bug with outsized consequences: a double-free of smc_spd_priv when tee() duplicates an SMC splice pipe buffer. The flaw sits in net/smc, where smc_rx_splice() allocates one private object per pipe_buffer and stores it in pipe_buffer.private, but the clone path only increments the page reference count and leaves the private pointer shared. That means two pipe buffers can later attempt to release the same object, leading first to a use-after-free and then, in the reported crash path, a NULL-pointer dereference and kernel panic. The published record also notes that the broader semantic problem remains even if the memory-safety issue is fixed with refcounting: duplicating an SMC splice buffer can corrupt receive-window accounting because the consumer cursor would advance twice for the same data. r Shared Memory Communications, is one of those Linux networking paths that most users never notice until something goes wrong. It exists for high-performance data transfer and is designed to minimize overhead in environments that care about latency, throughput, and CPU efficiency. That makes bugs in its splice and pipe-buffer handling especially interesting, because the code is expected to behave like infrastructure plumbing: invisible, deterministic, and safe under pressure.
The CVE description is unusually specific about the failure mode. smc_rx_splice() creates a per-buffer private state object, then stores it in the pipe buffer’s private field. When tee(2) duplicates the pipe buffer, the kernel’s generic buffer helpers copy the page-level state but do not duplicate the SMC-specific private object. As a result, both pipe buffers point to the same smc_spd_priv instance, and when they are released independently, the cleanup path runs twice. That is classic lifetime confusion, and in kernel space it is exactly the kind of mistake that turns into a crash or worse.
What makes this casvariety memory bug is the interaction with splice semantics. The SMC path was not designed to support duplication via tee() or partial transfers via splice_pipe_to_pipe(). The advisory text explicitly says the .get callback is invoked by both operations, and both now return -EFAULT. In other words, the kernel is not merely patching a bad free; it is changing the API contract so that the unsafe duplication path is blocked outright. That is a strong signal that the maintainers consider the behavior semantically wrong, not just technically buggy.
There is also a broader kernel-maintenana subsystem ties object lifetime to a pipe_buffer and then allows generic pipe operations to clone that buffer, the subsystem has to make a clear choice: either the private state is reference-counted correctly, or the duplication path must be forbidden. The upstream fix appears to choose the latter, which is often the safer answer when cursor accounting and data ownership are coupled.

Background​

The Linux kernel’s pipe and splice machinery itle subsystems. Pipes are not just a byte queue; they are a transport for page references, object ownership, and callback-driven cleanup. Once a subsystem stores custom state in pipe_buffer.private, it must be certain every path that can duplicate, move, or release that buffer knows how to preserve or retire that state correctly. That is where tee() becomes relevant, because tee() does not copy the data in the usual sense; it duplicates pipe buffers so two consumers can observe the same pages.
For ordinary pipe-backed data, that model is safe enough because the kernel can share references to page memory. But for SMC splice data, the private object is not just metadata. It participates in receive-side state tracking, including consumer progress updates. If two separate buffer lifetimes point to the same private object, they are no longer independent. They become a trap for whichever cleanup path runs second, because the first release has already torn down the state that the second release expects to exist.
The CVE text makes the panic chain very clear. The first release frees priv, droce, and updates consumer state in the correct order. The second release does the same thing, but now priv is already gone, so the path dereferences freed memory and falls into smc_rx_update_consumer() with a stale pointer. KASAN catches the slab-use-after-free in smc_rx_pipe_buf_release(), then the kernel trips a NULL-pointer dereference and panics. This is a textbook illustration of how object reuse bugs in the kernel are rarely confined to one line of code. They spread through the lifecycle.
A second important detail is the receive-window accounting. The advisory says even a reference-counted not fully solve the issue, because the consumer cursor would still advance twice for the same payload. That is a crucial distinction. A bug can be memory-safe and still wrong. In networking code, correctness is not optional: if the kernel believes data has been consumed twice, future reads, window updates, and backpressure decisions all become suspect.
The public record also shows this was not treated as a theoretical edge case. The CVE was published on April 22, 2026, and tmultiple stable kernel commits. That strongly suggests the issue moved through the usual Linux stable pipeline rather than being left as an isolated mainline fix. The fact that Microsoft’s vulnerability portal surfaced it as well reinforces the reality that Linux kernel defects now land in mixed-platform enterprise workflows just as often as Windows issues do.

---

How the Bug Happens​

The mechanics of the bug are straightforward once you separate the page reference from the private state. smc_rx_spedicatedsmc_spd_privobject for a pipe buffer. That object is then attached throughpipe_buffer.private, which means the release path expects to own it exclusively. Whentee()` clones that pipe buffer, however, the generic pipe helper only handles the page reference count. It does not know that the SMC path attached a second object with its own lifetime rules.

Shared pages, shared trouble​

The page itself is meant to be shareable. The private state is not. That mismatch is what creates the vulnerability. Two buffers nowthe pipe layer but are secretly coupled by the same smc_spd_priv *, so both release callbacks believe they are the sole owner of the object. The first one wins, the second one loses, and the second release becomes a use-after-free.
This is the kind of bug that tends to survive a long time in complex kernels because each layer appears correct in isolation. The pipe machinery is behaving as designed. The SMC code is bThe problem is at the seam, where the duplication semantics of one subsystem do not match the object-lifetime assumptions of the other. In kernel engineering, seams are where the hardest bugs live.
The crash trace in the advisory is useful because it shows the bug is not hypothetical. KASAN reports the freed object being read by smc_rx_pipe_buf_release(), then the release path cascades into free_pipese(), and __fput(). That is a normal cleanup chain, which means the kernel can stumble into the bug during a routine close of the pipe, not only during an exotic test harness. That makes the issue more operationally relevant than the word “splice” might suggest.

Why tee() is the trigger​

tee(2) is important because it duplicates pipe buffers without consuming the underlying data. That is a legitimate Unix-style optimization for zero-copy data movement, but it also means the implemey careful about ownership. If a buffer has attached private state, duplication is only safe when that state is either immutable and shareable or reference-counted with correct release semantics. The SMC path appears to satisfy neither requirement in the vulnerable version.
The advisory also mentions splice_pipe_to_pipe() as another path that invokes the .get callback for partial transfers. That matters because it means the unsafe assumption is not isolated to one syscall. It affects a broader set of pipe duplicatio by returning -EFAULT, closes off both entry points in one move. That is a strong indication that maintainers want to avoid any ambiguous copy-vs-share behavior in this path entirely.

• The page reference count was handled.
• The SMC private object was not.
• Both pipe buffers ended up sharing one smc_spd_priv.
• Cleanup ran twice against the same object.
• The second release turned into a use-after-free.

Why the Crash Escalates​

The first intehis CVE is that the memory bug is only half the story. A double-free is dangerous on its own, but the advisory points out a second failure mode: the freed priv->smc pointer is later chased by smc_rx_update_consumer(), which pr dereference. That means the object lifetime bug does not just destabilize the allocator; it poisons the control flow of the receive path itself.

From free to panic​

The release function does more than free memory. It also updates receive-side accounting and drops the socket reference. That means the stale object is not merely sitting unused after free; it is still participating in logic that expects it to be valid. Once the second release reaches inture, the kernel’s own safety mechanisms trigger a KASAN report, then a crash, then a full panic. In practice, that is a hard denial of service.
The trace also shows why these bugs are so frustrating to debug in the field. The first visible symptom may be the panic in smc_rx_update_consumer(), but the root cause is earlier, in the duplication of the pipe buffer. That is a common kernel pattern: the observable failure happens far from the original mistake. Operators who onle can miss the real fix entirely.
This is also why semantic correctness matters as much as memory safety. Even if the object were reference-counted, the consumer cursor issue would still remain. Two independent releases would still represent two logical consumptions of one data stream. The advisory explicitly says that duplicated SMC splice buffers are “semantically questionable” for not a side note; it is the heart of the vulnerability.
A well-designed fix in this situation has to do more than prevent the crash. It has to prevent the kernel from pretending that duplicated SMC data can be consumed twice. The decision to make the .get callback fail for these duplication operations suggests the maintainers chose to preserve correctness by disallowing a dangerous optimization path. That is often the right caere state and ownership are tightly coupled.

Impact on Enterprises​

For enterprises, the practical significance of this CVE depends heavily on whether SMC is actually enabled and whether workloads use splice-based duplication patterns. That makes it narrower than a generic networking issue, but not ignorable. High-performance Linux deployments in storage, data-transfer, and latency-sensitive environments are precisely the places where appear.

Operational exposure​

The obvious impact is a kernel panic. If a production host can be driven into the vulnerable path, the consequence is service interruption, possible failover, and in clustered environments, a broader cascading outage. The less obvious impact is data-path corruption if the receive cursor bookkeeping is exercised in ways that do not immediately crash. That kind of fault can be harder to detek like protocol instability rather than a security event.
Enterprises should also be thinking about their testing assumptions. A lot of kernel validation focuses on ordinary read/write behavior, not on tee() or partial splice duplication. This CVE is a reminder that zero-copy paths deserve special attention because they combine performance shortcuts with lifetime complexity. If a workload relies on those paths, the patch should be verified under realistic stress, not just installed and forgon this matters operationally is that many organizations do not run upstream kernels. They run vendor kernels, LTS branches, or appliance-specific builds. The CVE references stable commits, which is useful, but it also means defenders need to confirm that their vendor has actually backported the fix. Version strings alone can be misleading when the actual resolution is hidden in downstream patch sets.

• Hosts that use SMC are more relevant thsktops.
• Clustered and high-throughput systems face the greatest service-risk impact.
• Downstream backports matter more than mainline version numbers.
• Splice-heavy workflows should be regression-tested after patching.
• The cursor-accounting issue may matter even where the crash does not immediately appear.

Why the Fix Is Narrow but Important​

The most striking thing about the fix is that it is intentionallad of trying to invent a custom reference-counting scheme for smc_spd_priv, the kernel appears to reject the duplication path altogether. That choice reduces ambiguity and avoids the risk of creating a new bug while trying to repair the old one. In kernel maintenance, that restraint is often a sign of a healthy patch.

Rejecting unsafe duplication​

The advisory says tw returns -EFAULT for the affected duplication paths. That matters because it shifts the problem from runtime cleanup to upfront validation. In other words, the kernel decides that the operation is not valid for this object model and fails early. Early rejection is usually safer than trying to emulate copy semantics after the fact.
There is also a performance angle. A refcounted solution might have preserved some form of duplication, but at lex lifecycle handling and additional accounting work on every transfer. Blocking the path entirely avoids that complexity. That is especially appealing in a subsystem like SMC, which exists to be fast and simple on the hot path.
The downside, of course, is that users who expected to duplicate SMC splice data must now choose another method. The advisory explicitly says they must use a **copy-based read path meaningful compatibility tradeoff, but it is preferable to letting the kernel violate its own receive semantics. Sometimes the right answer is not to preserve a feature, but to narrow it to the cases where it is actually safe.
This patch also reflects a larger trend in kernel hardening: if a special-case optimization collides with hidden ownership semantics, gly prefer to disable the unsafe combination rather than maintain two parallel life cycles. That may feel less elegant, but it is often more robust. Kernel security work is full of those compromises, and this CVE is a good example of why.

Broader Linux Kernel Lessons​

This CVE is a compact example of a familiar kernel truth: lifetime rules are security rules. A private object attached to a buffer is only safe if every and release path understands how that object behaves. If one path copies the pointer without copying the ownership model, the bug is already planted.

Ownership boundaries matter​

Kernel developers often spend more effort reasoning about ownership than about raw memory. That is because the allocator is only one part of the story; the real problem is who is allowed to touch a structure an the pipe layer knew how to share the page but did not know how to share the SMC private object. That mismatch created a security issue even though no explicit buffer overflow existed.
The incident also reinforces the importance of testing weird syscall combinations. tee() and splice-to-pipe operations are not everyday desktop activity, but kernel CVEs fresely these less-traveled paths. The more a subsystem relies on generic plumbing, the more important it becomes to verify that its custom state obeys the same rules as the plumbing around it.
Another lesson is that “fixing the crash” is not always enough. The advisory explicitly warns that cursor accounting would still be wrong even if the private object were refcounted. That means the vulnerability is part crash bug, part protocol bug. Kernel ma wary of patches that only address the symptom while leaving the underlying semantics unclear.

• Custom pipe_buffer.private state needs explicit clone semantics.
• Reference counts do not automatically solve protocol correctness.
• Generic helpers are only safe when subsystem semantics match them.
• Denying unsafe combinations can be better than trying to support them.
• Edge-case syse same scrutiny as hot-path I/O.

Enterprise vs. Consumer Relevance​

For most consumer desktops, this is probably not a daily risk. SMC is not a mainstream desktop feature, and tee()-driven splice duplication is not the kind of workflow ordinary users trigger routinely. That does not make the bug unimportant, but it does narrow the real-world exposure window consideraatters most
In enterprise environments, especially on systems built for high-speed networking or specialized data movement, the picture changes. SMC tends to show up where teams care about offload efficiency and low-latency transport. Those are also the places where a kernel panic can have immediate service impact and where unusual I/O paths are mcised by automation or performance tooling.
For consumer users, the main practical takeaway is simpler: install kernel updates from your distribution as they become available. Even if this specific code path is unlikely to be hit on a laptop or gaming PC, kernel fixes are frequently bundled, and stability updates often contain multiple backportns. In that sense, patching this CVE is part of a broader maintenance discipline rather than a user-facing feature decision.
For enterprise teams, the distinction between “likely” and “possible” matters less than the operational blast radius. A bug that requires a particular feature stack can still be severe if it lives in a cluster, storage node, or infrastructure appliance. That is why the right question is not only “Can th also “What does a crash do to the service mesh around it?”

• Consumer relevance is probably limited by workload profile.
• Enterprise relevance is amplified by high-performance networking use cases.
• Kernel updates should still be applied through normal maintenance cycles.
• Infrastructure hosts deserve extra validation after patching.
• The operational cost of a panic can exceed the technical novelty of the bug.

Strengths and Opportunitally a good example of kernel security hygiene working as intended. The bug was identified, documented with a clear crash narrative, and then addressed through the stable-kernel pipeline. That makes it easier for operators to understand the issue and for vendors to backport a safe resolution without redesigning the subsystem.​

The patch also presents an opportunity for administratorsfleets use SMC and splice-based data paths. In many environments, the answer will be “not at all,” which is useful information in itself. In others, the fix may uncover a hidden dependency on zero-copy duplication semantics that should be revisited anyway.

• The fix is conceptually clear and operationally straightforward.
• The crash is well described by KAe backports should be easy for vendors to absorb.
• The patch reduces ambiguity in object lifetime handling.
• The advisory gives defenders a concrete trigger to audit SMC usage.
• Blocking unsafe duplication is safer than preserving a fragile optimization.
• The issue reinforces disciplined kernel patching habits.

Risks and Concerns​

The main concern is that the bug sits do not test aggressively. That makes it easy to underestimate, particularly if the organization treats SMC or splice paths as niche features. But niche does not mean harmless, and kernel crashes in specialized infrastructure often do disproportionate damage.
A second concern is semantic drift. Even if a vendor backports the memory-sible for downstream builds to diverge in subtle ways. If a vendor chooses a different implementation strategy, it needs to preserve both the lifetime fix and the receive-accounting constraint. Otherwise, the crash may disappear while the protocol bug remains.

• The vulnerable path may be under-tested in production.
• Downstream kernels can diverge from upstream fixes.
• Refcount-only thinking can miss the accounting issue.
• Closely rens may need audit.
• Error handling changes can surprise workloads that depended on duplication.
• Security scanners may not infer actual exposure from version numbers alone.
• The operational impact could still be a denial of service even without data corruption.

---

What to Watch Next​

The first thing to watch is vendor backport speecord references stable kernel commits rather than a brand-new API design, the practical remediation path should be a normal distribution update. The real question is which vendors incorporate the change promptly and how clearly they document it for customers who rely on enterprise kernels.
The second thing to watch is whether maintainers audit adjacent psimilar mistakes. Whenever one subsystem stores custom state in pipe_buffer.private, it is worth checking whether its clone and release callbacks are equally disciplined. The fact that the SMC fix blocks duplication outright may encourage a broader review of other zero-copy helpers with private metadata.
The third thing to watch is whether the public conversation around this CVE stays appropriately measured. This does not read like an easy remote-code-executild not be oversold as one. It is a serious kernel stability and correctness bug, with a real memory-safety component and a separate receive-accounting problem. Both matter, but they matter for different reasons.

• Watch for stable and vendor backports.
• Watch for related pipe-buffer lifetime audits.
• Watch whether distributions document -EFAULT behavior clearly.
• Watch for regressavy workloads.
• Watch whether adjacent zero-copy paths receive similar scrutiny.

CVE-2026-31507 is the kind of kernel flaw that reminds us why plumbing code deserves as much attention as headline-grabbing exploits. It is a bug about object ownership, protocol semantics, and the dangers of assuming that generic duplication rules automatically apply to custom state. The patch’s decision to reon is a sober one, and probably the right one, because the alternative would have been to preserve a feature the subsystem could not actually support safely. For defenders, the lesson is simple: patch it, verify the backport, and remember that in the Linux kernel, small lifetime mistakes can still end in a very large outage.

---

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