Linux ksmbd SMB vulnerability CVE-2024-22705 fixed in kernel 6.6.10

A subtle parse-time error in the Linux in‑kernel SMB server (ksmbd) can let a malformed SMB2 Create request provoke an out‑of‑bounds memory access in kernel space — a defect tracked as CVE‑2024‑22705 that was fixed upstream in the 6.6.10 stable release and that carries real, immediate availability risk for systems that expose the kernel’s SMB functionality. (cdn.kernel.org)

Background / Overview​

ksmbd is the Linux kernel’s in‑tree implementation of an SMB/CIFS server. Unlike user‑space Samba, ksmbd runs inside the kernel to reduce context switches and boost I/O performance for workloads that require heavy SMB throughput. That performance trade‑off comes with a risk surface: bugs in ksmbd execute with kernel privileges and can therefore crash or destabilize the entire system. The defect described by CVE‑2024‑22705 sits squarely in that risk class. (cdn.kernel.org)
At a high level: a logic error in smb2_get_data_area_len (fs/smb/server/smb2misc.c) can cause a call into smb_strndup_from_utf16 to read past an allocated slab buffer when a Create request’s Name and CreateContexts fields are malformed or mis‑related. The kernel fix — merged into the 6.6.10 stable tree — ensures the code validates the combined length of the Name and CreateContexts data area before attempting the UTF‑16 duplication, preventing the out‑of‑bounds read. (cdn.kernel.org)

---

What the CVE actually says (short, precise summary)​

• Vulnerable component: ksmbd (in‑kernel SMB server) inside Linux kernel source tree.
• Vulnerability location: function smb2_get_data_area_len in fs/smb/server/smb2misc.c; the problem manifests when smb_strndup_from_utf16 is invoked with miscalculated size. (cdn.kernel.org)
• Root cause: mishandling the relationship between Name data and CreateContexts data inside an SMB2 CREATE request, producing a slab out‑of‑bounds access.
• Fixed in: Linux kernel 6.6.10 (upstream stable release containing the corrective commit). (cdn.kernel.org)

---

Deep technical analysis: how malformed SMB2 triggers kernel memory access​

To understand why this is serious, we need to look briefly at the SMB2 CREATE request layout and what ksmbd was doing incorrectly.

SMB2 Create layout (conceptual)​

• An SMB2 CREATE request contains multiple variable‑length fields stored in a single request buffer.
• Two of those fields are the Name (filename to create/open) and CreateContexts (optional extra context blobs). Each has an offset and length encoded in the request header.
• Correct parsing requires strict bounds checks: offsets and lengths must lie within the request buffer and not overlap incorrectly.

Where ksmbd went wrong​

• The vulnerable code attempted to compute the "data area" containing Name and CreateContexts, but it did not account for the case where the two fields’ offsets/lengths relate such that a naive calculation underestimates the full area needed.
• When NameLength is non‑zero, the code failed to enforce that the computed data area includes the longer of the Name or CreateContexts ranges; as a result, smb_strndup_from_utf16 could be asked to copy characters beyond the validated buffer range, leading to a slab out‑of‑bounds read. (cdn.kernel.org)

Consequences of an OOB read in kernel SMB code​

• Even if the immediate failure is an out‑of‑bounds read (not a write), a read past a slab object can trigger a kernel OOPS, KASAN reports, or cause corrupted internal state that leads to a panic or persistent instability.
• Because ksmbd runs in kernel context and handles network requests, an attacker that can craft SMB2 CREATE requests (locally or from a privileged network path, depending on how ksmbd is exposed) can trigger repeated crashes or resource exhaustion — resulting in sustained or persistent loss of availability to SMB resources. Multiple public advisories rate the impact as high for confidentiality, integrity, and availability.

---

Scope and real‑world exposure​

• Upstream scope: any Linux kernel build that includes ksmbd and is older than the 6.6.10 fix is potentially affected. The upstream changelog documents the corrective commit applied to 6.6.10. (cdn.kernel.org)
• Distribution scope: several Linux distributors published tracking entries and advisories mapping the CVE to their package trees; Debian, SUSE and others included it in their trackers and advisories. Administrators should consult their vendor advisory for exact package versions and vendor backport decisions.
• Attack vector nuance: most canonical vulnerability records classify this as a local attack vector with low required privileges (CVSS/3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H in many vendor assessments), which means an attacker typically needs some level of local access or the ability to send requests that the kernel will accept as local SMB server requests. Some vendors have scored the problem differently when considering remote exposure in certain deployment contexts — for instance, when ksmbd is bound to a public network and SMB ports are reachable. Administrators must evaluate their deployment topology to determine if ksmbd is reachable from untrusted networks.

---

Exploitability and threat realism​

• Public telemetry: as of the latest public enumerations, there are no widely circulated, reliable proof‑of‑concept exploits in the wild for remote, unauthenticated exploitation of CVE‑2024‑22705. Product trackers list EPSS and exploitation likelihood metrics that are low to moderate. That said, EPSS and exploitability metrics evolve; attackers frequently weaponize kernel bugs once a reliable trigger and packet sequence is known.
• Practical attack scenarios:
• Local authenticated attacker (e.g., unprivileged user on the host) could interact with local ksmbd socket or IPC and craft malformed CREATE requests to crash ksmbd in kernel, producing denials or OOPS messages.
• Remote attacker in misconfigured deployments: if ksmbd is listening on an externally reachable interface (port 445/139) and the host lacks adequate network filtering, remote actors could attempt to trigger the condition. Vendors disagree on remote feasibility; treat any exposure of SMB ports to untrusted networks as high risk.

---

Detection, forensics and indicators of compromise​

When hunting for attempts to trigger this bug, operators should look for kernel logs and abnormal kernel messages correlated with SMB activity:

• Kernel oops/panic or repeated "ksmbd" stack traces in dmesg and /var/log/kern.log.
• KASAN warnings that mention smb_strndup_from_utf16, smb2_open, smb2misc.c or the ksmbd code paths.
• Sudden failures of SMB mounts, failed opens or immediate connection terminations from Windows clients after issuing CREATE operations.
• Service restarts or crashes of the ksmbd module; check systemctl status for any ksmbd service unit or monitor module unload/load events. Several distribution trackers explicitly note kernel OOPS patterns for related ksmbd bugs; these vendor pages can help tune detection rules.

Practical detection commands (examples)

• Check kernel version:
• uname -r
• Inspect module and service state:
• lsmod | grep ksmbd
• systemctl list-units --type=service | grep -i ksmbd
• Search dmesg and logs for ksmbd/oops signatures:
• sudo dmesg --ctime | grep -iE 'ksmbd|smb_strndup_from_utf16|smb2_open|smb2misc'
• sudo journalctl -k | grep -i ksmbd

---

Remediation and mitigation: concrete steps for administrators​

The canonical remediation is to install a kernel that includes the upstream fix (6.6.10 or later), or to apply your vendor’s backported patch for the distribution kernel. If you cannot immediately upgrade, use the temporary mitigations below.
Primary fix: update the kernel

• Apply vendor kernel updates that include the 6.6.10 upstream fix or equivalent backport for your distribution. Check your distribution’s security advisory for the CVE mapping and package versions. Debian, SUSE, and major vendors list fixes/backports for affected trees.

If you cannot patch immediately: temporary mitigations

• Disable or stop in‑kernel SMB (ksmbd) service until patched:
• If your distro provides a ksmbd service unit: sudo systemctl stop ksmbd && sudo systemctl disable ksmbd
• Unload the kernel module if it’s a loadable module: sudo modprobe -r ksmbd (note: unloading kernel modules that are in use may fail; plan maintenance windows).
• Block SMB/TCP ports (445 and 139) at the host firewall and at network perimeter devices — prevent untrusted networks from reaching SMB listeners.
• Example: sudo iptables -A INPUT -p tcp --dport 445 -j DROP (modern distros may use nftables or firewalld; adapt commands accordingly).
• Restrict access to trusted hosts/networks only by host firewall rules or TCP wrappers.
• Consider running Samba or an alternative user‑space SMB server instead of ksmbd where kernel‑level SMB server exposure is unacceptable for your threat model.

Operational cautions

• Removing or disabling ksmbd may interrupt active SMB sessions — plan maintenance windows and notify users.
• Kernel upgrades can have broader compatibility implications (drivers, custom modules). If you apply a vendor backport, prefer the vendor’s validated packages to avoid regressions.

---

Step‑by‑step hardened checklist (recommended)​

• Inventory: identify all hosts running kernels with ksmbd enabled.
• grep -R "CONFIG_KSMBD" /boot/config-$(uname -r) or check lsmod.
• Assess exposure: confirm whether ports 445/139 are reachable from untrusted networks.
• ss -ltnp | grep -E ':445|:139'
• Patch: schedule kernel updates — apply the vendor patch that maps to the CVE or upgrade to a kernel containing the 6.6.10 fix.
• If immediate patching is impossible:
• Stop ksmbd service; unload module where possible.
• Block SMB inbound on perimeter and host firewalls.
• Monitor: set alerts for kernel oops messages that reference ksmbd or the affected functions.
• Post‑patch validation: after applying patches, verify there are no ksmbd‑related OOPS messages and that SMB functionality behaves correctly from clients.

---

Why the fix is straightforward — and why the risk remains non‑trivial​

The upstream corrective change applied to the 6.6.10 changelog is concise: it enforces a correct minimum data area calculation so smb_strndup_from_utf16 cannot be asked to copy beyond validated bounds. That kind of fix is generally reliable — it's a proper input‑validation correction rather than a complex logic rewrite. (cdn.kernel.org)
However, the broader risk stems from two realities:

• The bug lives in kernel space; failure modes create OOPS/panic fallout rather than a limited user‑space crash. Kernel crashes are much more damaging operationally.
• ksmbd is a protocol implementation that parses complex, variable‑length network structures. That parsing surface has been the source of several recent kernel CVEs; administrators should treat any in‑kernel protocol parsers as higher‑risk components and prefer vendor‑backporting or removal if not required. Forum and tracker histories show multiple ksmbd fixes across 2023–2025, underscoring the subsystem’s evolving maturity. (cdn.kernel.org)

---

Vendor disparity and the need to check your distro’s advisory​

Different distributions may map CVSS vectors or the attack vector differently (some treat the vector as local; some score as adjacent network in specific cloud images). Do not assume a global risk posture based on a single CVSS number — consult your vendor advisory and the package‑level fixes for your distribution. Debian, SUSE, Amazon Linux trackers and other vendor pages already show mapping entries and patch status for this CVE, so cross‑checking your distro’s CVE status is essential.

---

Longer term recommendations for operators and vendors​

• Limit in‑kernel protocol surface: Where possible, favor user‑space protocol servers (Samba) that can be sandboxed and updated independently of the kernel.
• Aggressive fuzzing and continuous integration for in‑kernel parsers: ksmbd’s repeated fixes show the value of proactive, instrumented fuzz testing and KASAN/UBSAN coverage for subsystems that parse remote inputs.
• Vendor transparency on backports: Distributors should clearly document whether a kernel backport is issued and which package versions contain fixes, including for long‑term support (LTS) kernels. Several distributed trackers do this, but mapping completeness varies across vendors — operators should not assume a patch exists for an older kernel without explicit vendor confirmation.

---

Final assessment: practical risk and recommended response​

• Practical risk today: High for availability on systems that expose ksmbd to untrusted traffic and that run an affected kernel. The bug is a slab out‑of‑bounds access in kernel SMB parsing code; repeated triggers can produce OOPS or persistent service loss. Public scoring generally places this CVE as high severity.
• Immediate recommended actions:
• Prioritize patching kernel packages that include the 6.6.10 fix or vendor backport.
• If patching is delayed, temporarily stop ksmbd and block SMB ports at network and host firewalls.
• Monitor kernel logs for ksmbd-related oops and KASAN traces, and instrument detection rules to catch suspicious CREATE sequences or repeated SMB session failures.
• Longer term: consider whether an in‑kernel SMB server is necessary in your environment; if not, disable it and use a user‑space alternative that can be updated more rapidly and sandboxed.

---

CVE‑class vulnerabilities that execute in kernel space carry a fundamentally higher operational cost than user‑space bugs: the fix may be small, but the blast radius is the whole host. CVE‑2024‑22705 is precisely that kind of bug — a compact parsing error with outsized availability impact unless mitigated promptly. Apply vendor patches where available, close any SMB exposure to untrusted networks immediately, and treat in‑kernel protocol parsers as high‑priority components for both hardening and continuous validation. (cdn.kernel.org)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center