The Linux kernel received a narrowly scoped but operationally meaningful security fix this week: a resource-accounting leak in the in‑kernel SMB server (ksmbd) was corrected to ensure the per‑transport connection counter
active_num_conn is decremented on connection setup failures, closing CVE‑2026‑23228 and preventing a subtle resource exhaustion/denial‑of‑service vector for SMB server hosts.
Background
ksmbd is Linux’s in‑kernel implementation of the SMB/CIFS server protocol. It was added to improve throughput and reduce context switches compared with userspace SMB servers, and over the last several years it has accumulated a number of targeted hardening fixes addressing races, reference‑counting bugs and edge‑case frees. Those prior fixes — which closed use‑after‑free and refcount leaks in session/session‑setup paths — prove the code nrivial to get right.
CVE‑2026‑23228 is not a glamourous memory‑corruption bug; it is an accounting bug. On a particular error path inside ksmbd_tcp_new_connection(), the code used free_transport() to release a transport object when kthread_run() failed. free_transport() frees transport resources but does
not decrement the global/per‑listener counter active_num_conn that tracks active ksmbd connections. The result: a leak of that counter over repeated failures that could allow the server to report (and act on) an inflated number of active connections, leading to access to incorrect state, resource-management surprises, and — under sustained triggering — potential availability impacts. The fix swapped free_transport() for ksmbd_tcp_disconnect(), which ensures the counter is decremented correctly during cleanup.
What exactly went wrong (technical overview)
The actors: transport, threads, and the counter
- ksmbd creates a per‑connection transport object to represent a newly accepted TCP socket.
- A kernel thread (kthread) is started to service that transport; registration and accounting logic increments active_num_conn when the transport becomes active.
- If thread creation (kthread_run()) fails — a realistic low‑probability event on heavily loaded systems or when kernel thread resources are constrained — code must unwind and release the transport.
The bug: mismatched cleanup
- On the kthread_run() failure path the code called free_transport(), which performs resource release but does not decrement active_num_conn.
- That left the counter higher than the actual number of live transports. Over many repeated failures (or an attacker‑driven rapid connect/disconnect storm), the counter can drift upward, eventually causing the subsystem's internal assumptions to break or to prevent new connections from being accepted if tests depend on the counter. The practical consequence is a logical resource leak — not a classic memory leak but an accounting leak that can degrade availability.
The fix
- Replace the free_transport() call on that error path with ksmbd_tcp_disconnect(), which performs the transport shutdown path that also decrements active_num_conn reliably.
- The change is surgical: it corrects the cleanup routine invoked on that failure path so the transport teardown goes through the same logic as normal disconnects. Multiple patch traces and distribution trackers list the relevant commits and confirm this was the intended fix.
How serious is CVE‑2026‑23228?
Short answer:
operationally important but not a remote code execution (RCE) elevation-of-privilege issue. Multiple vulnerability trackers and distribution advisories classify this as a correctness/resource leak fix rather than an arbitrary‑code or privilege escalation vulnerability. The National Vulnerability Database (NVD) entry and major distro trackers describe the issue as a fix to avoid leaking the
active_num_conn counter on a specific kthread_run() failure path.
That said, risk is not zero:
- If an attacker (or a misconfigured client) can repeatedly trigger the specific failure path — for example, by generating numerous short‑lived connection attempts that reliably fail during thread creation — the server could accumulate accounting errors and eventually exhibit degraded behavior: refusing new connections, incorrect load decisioning, or other availability impacts.
- The vulnerability is not a direct route to kernel code execution or privilege escalation as described; there is no public proof-of‑concept indicating memory corruption or arbitrary‑write primitives. Multiple sources list no remote exploitation capability for code execution.
Be wary of scanning feed parsers: automated vulnerability scanners sometimes inflate severity for kernel fixes that touch networking or widely used services. For example, some scanner plugins may mark the issue as “critical” because it affects a kernel SMB component, while NVD / distro documentation do not assign an RCE-style severity here. Treat those scanner outputs as triage signals, not definitive exploitability proofs.
Who and what is affected
- The vulnerability originates in the Linux kernel ksmbd server codebase and therefore can affect any distribution shipping a kernel with the vulnerable ksmbd revision.
- Distribution trackers (Ubuntu, Debian, etc.) have registered the CVE and are evaluating or publishing package updates; upstream stable tree commit ranges indicate which kernel versions contain the fix. Administrators should consult their distribution’s security tracker to see whether a security update is available for their kernel package.
- Because this is a kernel‑level SMB server, appliances, NAS devices, or virtual machine guest images that use vendor kernels may also be impacted until their maintainers backport the correction and ship updates. Vendor‑specific slowness to patch kernel trees is a common operational risk vector in this class of bug.
Confirming the fix — cross‑checks and evidence
I cross‑checked the publicly available trackers and distribution advisories to confirm both the cause and the prescribed remediation:
- The NVD entry and multiple CVE aggregators summarize the defect as the leaked active_num_conn counter on kthread_run() failure and note the corrective replacement of free_transport() with ksmbd_tcp_disconnect().
- Ubuntu, Debian and other distro trackers list the CVE and note evaluation/patching status for supported releases, which corroborates the fix and signals downstream patch activity.
- Several CVE aggregators and security trackers point at the kernel stable commits that implement the fix (the fix is visible in upstream and stable trees), and vendor distro pages reference those commits as the authoritative change set. While git.kernel.org access to raw commit pages may be limited for some readers, the presence of stable‑tree commit hashes in multiple independent trackers is strong corroboration.
If you need to absolutely confirm whether your running kernel contains the fix, check your kernel's version against your distribution's security advisory or the stable‑tree commit IDs published by your vendor. If your distro provides a security advisory number for CVE‑2026‑23228, apply it in your usual change control process.
Practical mitigation and hardening guidance (for administrators)
The remediation is simple in concept — install the kernel patch or updated kernel package — but operational constraints mean administrators must triage and mitigate carefully. Follow this prioritized checklist:
- Identify: Determine whether ksmbd is enabled on the host. If you do not use in‑kernel ksmbd (for example, you run Samba in userspace), this CVE is not applicable. Check loaded modules and services for ksmbd, cifs, or smbd functionality.
- Inventory kernels: Record the kernel version(s) running on internet‑facing SMB hosts, file servers, NAS devices, and hypervisor guests. Compare them against your distro’s advisory for CVE‑2026‑23228.
- Patch priority: If ksmbd is present on production file servers or appliances, prioritize kernel updates for those hosts. Where possible, apply vendor kernel updates that specifically list CVE‑2026‑23228 or include the upstream commit that replaces free_transport() with ksmbd_tcp_disconnect().
- Temporary risk reduction:
- If you cannot patch immediately, limit exposure: block incoming SMB (TCP ports 445 and 139) at the network edge for hosts that do not need external SMB access.
- Use host or network rate‑limiting to reduce the ability to rapidly cycle connections to the SMB server; connection rate limits reduce the chance an attacker can drive repeated failure paths that trigger the accounting leak.
- If ksmbd can be disabled and an alternative SMB server (e.g., Samba userspace) is acceptable, consider disabling the ksmbd module until a patch is applied.
- Monitor: Add alerts to detect unusual, high‑volume connect/disconnect patterns against SMB listeners and monitor the server for erratic connection counters or resource exhaustion. Instrumentation that looks for disconnect storms or rapidly failing kthread starts will help detect exploitation attempts.
- Test patch in staging: Because kernel updates can have side effects, stage the patched kernel on representative systems and run I/O and SMB workload tests before fleet rollout.
- Vendor appliances: If your file server is vendor‑supplied (OEM NAS, embedded appliances), contact the vendor for firmware or kernel updates; these vendors often patch on different schedules and may require manual firmware upgrades.
These steps balance emergency mitigation with operational stability and give you an audit trail for patch prioritization decisions.
Detection and forensics: what to look for
This class of accounting leak leaves operational traces rather than memory corruption artifacts. Useful signals include:
- Abnormally high or rising internal connection counters or metrics exposed by ksmbd instrumentation.
- Rapid cycles of connection accept followed almost immediately by thread-start failures (look for kthread_run failure messages in kernel logs).
- Repeated short lived TCP connections to SMB ports, or many SYNs that do not complete the thread creation lifecycle.
- Kernel logs (dmesg) indicating ksmbd traed by the ksmbd subsystem.
If you observe these signals and you have not yet applied the patch, treat them as high priority for immediate investigation and mitigation.
Wider context: ksmbd’s recent CVE history and why it matters
ksmbd has been the subject of targeted hardening work over the last 24 months: fixes for session refcount leaks, input‑validation hardening for IPC payloads, and other race‑and‑shutdown related bugs are recent and show a sustained upstream care cycle. Those prior CVEs — while different in severity — underscore that in‑kernel SMB is complex and that seemingly small control‑flow differences in disconnect paths can create operationally significant bugs.
The practical lesson for ops teams: kernel‑level protocol implementations are fast and efficient, but they raise the stakes for correctness. When issues are found, the fixes are usually specific and safe, but distributors and appliance vendors must still test and ship them carefully.
Discrepancies in scanner severity and why you should care
Security scanners and vulnerability feeds do not always agree on severity for kernel fixes that do not enable code execution. Some Nessus plugins and third‑party scanners flagged this CVE with higher severity metrics; distribution advisories and NVD did not assign a remote‑code execution classification. This mismatch is common with kernel networking fixes:
- Automated scanners often apply generic heuristics (kernel + SMB = severe) and may propose high CVSS values.
- Upstream and distro advisories more carefully classify the technical impact; for CVE‑2026‑23228 the technical impact is logical resource leak and potential availability impact, not RCE.
Action: treat scanner alerts as a triage cue. Verify the underlying technical detail from the vendor advisory or upstream commit before escalating to “critical” change windows.
Recommended timeline for remediation
- Immediate (0–72 hours): Inventory, apply network mitigations (block SMB if not needed), rate‑limit incoming connections, and identify critical ksmbd hosts.
- Short term (3–14 days): Test and deploy patched kernels for high‑risk production hosts and appliances; stage remaining systems for patching.
- Medium term (2–6 weeks): Roll out patches across the estate, update monitoring rules, and review appliance vendor patch responsiveness.
- Long term (quarterly): Include kernel SMB components in cyclic risk assessments and threat models; maintain a vendor patching SLA for appliance kernels.
Final assessment and takeaways
CVE‑2026‑23228 is a pragmatic kernel fix: it closes an accounting leak in the ksmbd connection‑setup error path so that
active_num_conn no longer drifts when kthread creation fails. The technical risk is predominantly availability/DoS related rather than code execution or privilege escalation. Still — because SMB servers are core infrastructure components and ksmbd runs in kernel context — the practical impact of unpatched systems can be real; attackers or misconfigured clients could trigger the failure path repeatedly to stress a server’s connection accounting and availability.
Operationally: prioritize patching for production file servers and appliances that expose SMB services, use network controls to limit exposure, and add monitoring to detect connection storms. For teams that run ksmbd‑enabled kernels in production, this CVE is
important to address even if it is not an RCE or privilege escalation vulnerability.
If you manage file servers or appliances that use Linux kernels with ksmbd enabled, treat this like any other kernel‑level service fix: confirm applicability, stage the kernel update, and roll it out on a controlled schedule while monitoring both availability and performance after the upgrade. The bug itself is fixed upstream and distributors are already tracking and shipping the necessary corrections — your practical job is to ensure those kernel updates reach the systems that matter.
Acknowledgement: the fix, description, and distribution tracking for CVE‑2026‑23228 are documented in upstream security trackers and distribution advisories; I relied on multiple independent public trackers and distro security pages to cross‑check the technical description and the remediation approach.
Source: MSRC
Security Update Guide - Microsoft Security Response Center