ksmbd SMB3 multichannel race exposes kernel signing keys

At a glance

What this is: This is an analysis of CVE-2026-23226 in Linux ksmbd, where an SMB3 multichannel use-after-free can expose signing keys and crash the kernel.

Why it matters: It matters because privileged network file-sharing paths can turn a concurrency bug into credential exposure and service disruption, which changes how teams should govern exposure, patching, and monitoring.

By the numbers:

• The report says the exploit needs about 1 hit per 750 attempts.

Context

ksmbd is the Linux kernel-native SMB server, so a flaw in its multichannel handling is not a userspace bug but a kernel-integrity problem. In this case, an authenticated remote client can race session teardown against channel lookup and force the kernel to read freed memory.

The governance issue is that SMB3 multichannel creates shared mutable state across concurrent connections. Once a channel object can be freed while another thread still trusts it, the control model shifts from ordinary file-sharing access to privileged network access with signing-key exposure.

Orca Security’s analysis shows that the attack depends on a valid SMB session, port 445 reachability, and multichannel being enabled. That combination is narrower than generic SMB exposure, but it is still broad enough to matter in environments that treat kernel services as implicitly trusted.

Key questions

Q: What breaks when ksmbd multichannel is enabled on an exposed server?

A: The binding path can race with teardown and free a channel object while another thread still reads it. In practice, that can expose the per-channel signing key or crash the kernel, so the failure is not just instability but loss of trust in SMB3 session integrity.

Q: Why does this ksmbd bug matter if attackers still need valid credentials?

A: Valid credentials reduce the attacker pool, but they do not remove the vulnerability. Once an authenticated user can reach SMB3 multichannel, the exploit can turn ordinary access into a race against shared kernel state, which is enough to expose signing material or deny service.

Q: What are the signs that kernel SMB exposure is too broad?

A: Look for ksmbd on hosts with port 445 reachable beyond tightly controlled networks, especially where multichannel is enabled and the kernel is not on a fixed build. Those conditions create the reachable surface the race needs, even when no active exploitation is visible.

Q: Should teams disable SMB3 multichannel or just patch ksmbd?

A: Patch first, but disable multichannel if patch rollout will lag or if the service is not operationally required. Multichannel is what opens the vulnerable binding path, so removing it shrinks risk immediately while the kernel fix is deployed and validated.

Technical breakdown

How SMB3 multichannel creates shared kernel state

SMB3 multichannel lets one authenticated session use multiple TCP connections at the same time. In ksmbd, those channels are tracked in a session-level XArray, which means the server must coordinate concurrent lookup, insert, and delete operations across worker threads. The bug appears because the binding path for a second connection reads the channel list while teardown on another connection can erase and free the same channel object. The failure is not protocol validation, which is correct, but concurrent state management in kernel memory.

Practical implication: Treat multichannel as a concurrency-sensitive kernel feature and review whether it should be enabled at all on exposed servers.

Why a use-after-free exposes the signing key

The freed object is a small channel structure that holds the per-channel AES-128-CMAC signing key and a connection pointer. When the lookup path reads that memory after free, it can recover the original key if the slab slot has not been reused, or it can read corrupted data if another allocation has overwritten it. Because the code frees the object immediately rather than deferring reclamation with a grace period, the read and free paths have no safe handoff. That is what turns a race into both integrity loss and information exposure.

Practical implication: Treat immediate free of shared kernel identity state as a security boundary and verify whether any concurrent reader can still reach the object.

Why session teardown does not close the race window

ksmbd waits for in-flight work on the connection being torn down, but it does not impose a session-wide barrier across all connections that share the same authenticated session. That means one connection can continue processing signed requests while another connection deletes the shared channel object. On a multithreaded system, that gap can be wide enough to reproduce reliably under load. The architectural problem is not just missing locking, but missing lifecycle coordination for state shared across sibling connections.

Practical implication: Audit teardown paths for session-scoped barriers, not just per-connection cleanup, when shared authentication state exists.

Threat narrative

Attacker objective: The attacker aims to recover channel signing material and destabilize the kernel so SMB3 traffic can be forged or the server denied service.

1. Entry occurs over SMB3 on port 445 after the attacker authenticates with valid SMB credentials and reaches the multichannel binding path.
2. Credential and state access happen when the second connection reuses the authenticated session and races channel lookup against teardown of the shared channel object.
3. Impact follows when the kernel reads freed memory, exposing the signing key or panicking the system, which can break integrity and availability.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kernel-native file sharing is no longer a simple SMB administration problem. Once file sharing moves into the kernel, the identity and access boundary shifts with it. ksmbd shows that concurrent session state can become a security primitive in its own right, because the kernel is now storing and protecting signing material on behalf of a network client. The practitioner implication is that exposed kernel services must be governed as privileged access surfaces, not as ordinary file servers.

Shared-session lifecycle is the real failure mode here. The bug worked because one connection could tear down a channel object while another still had a legitimate reference path through the same session. That is a lifecycle governance problem, not just a memory-safety problem. The implication is that session-scoped identity state needs explicit ownership and coordinated teardown wherever multiple connections can share the same authenticated context.

Access review assumptions do not help when the vulnerability lives inside the runtime path. Access reviews and periodic governance assume the risky state persists long enough to be reviewed. Here, the dangerous condition emerges and disappears inside a race window measured in worker scheduling, so the control problem moves to runtime coordination and exposure reduction. Practitioners should treat multichannel-enabled ksmbd as a high-risk exception path, especially where port 445 is reachable from untrusted networks.

Kernel identity exposure can collapse both integrity and availability at once. The article’s key lesson is that a signing key leak and a kernel panic can come from the same shared-state defect. That makes the issue materially different from a generic crash bug, because the object being protected is not just memory but session trust itself. Teams should therefore align patching, segmentation, and service exposure decisions around identity-bearing kernel components, not only around exploit code execution.

Channel-list locking is a specific governance concept worth naming: multichannel shared-state isolation. In ksmbd, the channel list needed a lock because multiple authenticated connections were allowed to mutate and read the same session-bound structure. Without that isolation, the session’s signing key becomes reachable through a race instead of through authorization. For practitioners, the lesson is to inventory any kernel or appliance service that reuses authenticated state across concurrent channels and verify its lifecycle isolation.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: NHI Security Platform Buyer's Guide

What this signals

Multichannel-enabled kernel services should now be treated as identity-bearing infrastructure. The problem is not only memory safety but the fact that shared session state carries signing authority across concurrent connections. That means your exposure management should separate ordinary SMB access from kernel-native SMB access and prioritise the latter wherever port 445 is externally reachable.

Session lifecycle, not just authentication, is the control boundary that failed here. Authentication was valid, dialect checks passed, and the bug still existed because the teardown path did not protect the shared channel object long enough. For practitioners, that means reviewing whether any runtime identity state can be freed while sibling workers still depend on it.

Kernel-native file services expand the blast radius of access decisions. A single race can reveal signing material and trigger a crash, so exposure reduction matters even after patching. If multichannel is required, segment it aggressively and monitor for any host where ksmbd and internet-reachable SMB coexist.

For practitioners

• Patch kernels that include the vulnerable ksmbd commit Update systems to a build that includes the fix merged in commit e4a8a96a93d. Treat this as a kernel remediation, not a userspace package update, and verify distribution backports before declaring exposure closed.
• Disable SMB3 multichannel where it is not required If update timing is uncertain, remove the attack path by setting smb3 multichannel = yes to disabled in ksmbd configuration or otherwise preventing the binding code path from being reachable.
• Inventory port 445 exposure on ksmbd hosts Prioritise hosts where ksmbd is present and SMB port 445 is reachable from untrusted networks, because those are the systems where the race can be exercised remotely after authentication.
• Validate whether kernel-native SMB is actually in use Confirm whether the service is ksmbd rather than userspace Samba, because the vulnerability is specific to the kernel implementation and the remediation path depends on that distinction.
• Review shared-session teardown paths for race windows Map any session-scoped kernel state that can be read by one worker while another worker frees it, then confirm whether the teardown path has a session-wide barrier rather than only per-connection cleanup.

Key takeaways

• The vulnerability shows that a shared kernel channel object can be freed while another thread still trusts it, which turns SMB3 multichannel into a trust-break problem, not only a crash bug.
• Orca Security reports that the exploit can expose a per-channel AES-128-CMAC key and that the race can be reproduced with about 1 hit per 750 attempts under the right conditions.
• The decisive control is to remove the vulnerable binding path by patching the kernel and disabling multichannel wherever that feature is not operationally necessary.

Key terms

• SMB3 multichannel: SMB3 multichannel allows one authenticated SMB session to use multiple TCP connections at the same time. In practice, it increases throughput, but it also creates shared server-side state that must be synchronised carefully because several worker paths may read and delete the same channel data concurrently.
• Use-after-free: A use-after-free occurs when code continues to read or write memory after it has already been released. In kernel networking paths, this often becomes a security issue because stale pointers can expose secrets, corrupt control flow, or crash the system under the right timing conditions.
• Public-Key Exposure: The condition where public keys are visible in a way that creates long-term attack value, such as on-chain transaction data or reused address formats. Exposure is not a vulnerability by itself, but it becomes a serious risk when future advances can turn it into private-key compromise.
• Race Condition: A race condition is a timing flaw where security decisions depend on state that can change before the action completes. In identity and payment systems, it allows attackers to split one harmful outcome into several individually valid steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.