CVE-2024-26594

What it actually does

This vulnerability is in ksmbd, the in-kernel SMB server implementation in Linux. During SMB session setup, ksmbd failed to properly validate the authentication mechanism token supplied by a client. A malformed or invalid mechanism token could drive ksmbd into unsafe memory handling, consistent with a memory-corruption/use-after-free class issue. The practical impact is exposure of sensitive kernel memory and/or kernel crash conditions, reflected by high confidentiality and availability impact. The supplied CVSS vector indicates exploitation requires local access with low privileges and no user interaction, but in operational terms the risk is concentrated on Linux systems where ksmbd is enabled and reachable by untrusted users or clients.

Why it matters to the business

Successful exploitation can disrupt file-sharing services or crash affected Linux hosts, causing outages for SMB-backed storage, file servers, appliances, or embedded systems that rely on ksmbd. Because the flaw can also expose sensitive memory, it may lead to leakage of credentials, file-sharing metadata, kernel data, or other information processed by the host. Although it is not currently listed in CISA KEV and no mature public exploit is indicated, the EPSS score is elevated, so internet- or broadly reachable ksmbd deployments should be treated as higher priority for patching and exposure reduction.

How an attack unfolds

An attacker first needs access to a system where ksmbd is enabled and accepts SMB session setup traffic. The attacker initiates an SMB connection and proceeds to the authentication/session setup phase. Instead of sending a valid authentication mechanism token, the attacker sends a deliberately malformed or invalid token designed to exercise the missing validation path in ksmbd. Vulnerable kernels may mishandle the token in kernel memory, resulting in a kernel fault, service disruption, or potential disclosure of sensitive memory contents. There are no confirmed named threat actors or KEV-backed exploitation campaigns tied to this issue in the supplied data; however, the elevated EPSS score warrants proactive treatment, especially for file-serving Linux systems.

How to fix it

Upgrade the Linux kernel to a vendor-supported build that includes the ksmbd fix. For source-based tracking of the stable Linux kernel tree, ensure the fix commit dd1de9268745f0eac83a430db7afc32cbd62e84b, or an equivalent backport from the relevant distribution vendor, is present. Because the fixed version is expressed as an upstream Git commit, package-based environments should rely on the distribution’s security advisory and install the corrected kernel package for the active release stream, then reboot into the updated kernel. If immediate patching is not possible, disable ksmbd if it is not required, unload or blacklist the ksmbd kernel module where feasible, stop related ksmbd user-space management services, and restrict SMB access to trusted networks only. Do not rely solely on network filtering if untrusted local users or adjacent systems can still reach the service.

How to confirm the fix worked

Confirm exposure by checking whether ksmbd is present and active, for example by reviewing loaded kernel modules, listening SMB services, and ksmbd management processes. Validate remediation by confirming the running kernel version maps to a vendor advisory that includes the fix or by verifying that the source tree contains commit dd1de9268745f0eac83a430db7afc32cbd62e84b or its backport. After patching, reboot and confirm the host is running the updated kernel rather than only having the package installed. Where ksmbd is not required, validate that the ksmbd module is not loaded, ksmbd-related services are disabled, and TCP/445 is not exposed except where explicitly intended. Review kernel logs after validation testing for absence of ksmbd-related oops, KASAN, general protection fault, or panic messages during SMB session setup attempts.

Typical attack path

1. Identify Linux systems exposing SMB service backed by ksmbd rather than only user-space Samba.
2. Confirm that the target accepts SMB session setup attempts from the attacker’s network or local access context.
3. Open an SMB connection to the target service.
4. Send a session setup request containing an invalid or malformed authentication mechanism token.
5. Trigger unsafe token handling in the vulnerable ksmbd code path.
6. Observe resulting effects such as kernel oops, host crash, SMB service interruption, or possible memory disclosure.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and SMB service telemetry for ksmbd faults or crashes correlated with SMB session setup attempts. Relevant sources include journald, dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, kernel crash dump directories, and any network telemetry for TCP/445. Look for kernel oops, panic, KASAN, use-after-free, slab, general protection fault, or NULL pointer messages that include ksmbd functions or occur immediately after SMB2 SESSION_SETUP traffic. If packet captures or IDS metadata are available, investigate malformed SPNEGO/GSS-API authentication tokens in SMB session setup requests. Because exploitation may only produce a crash or memory disclosure without a durable file artifact, absence of filesystem indicators does not rule out exploitation. Preserve crash dumps and kernel logs before rebooting or rotating logs, and correlate source IPs that repeatedly initiate SMB session setup failures or precede host instability.

• ksmbd
• ksmbd.mountd
• ksmbd:
• SMB2 SESSION_SETUP
• SESSION_SETUP
• invalid mech token
• mech token
• SPNEGO
• GSS-API
• BUG: KASAN
• use-after-free
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• Unable to handle kernel
• slab-out-of-bounds
• ksmbd_smb2_session_setup
• smb2_sess_setup
• /sys/module/ksmbd
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• tcp/445

What your security team should do

• Inventory Linux systems using ksmbd and prioritize hosts exposing SMB to untrusted networks or shared user populations.
• Patch affected kernels to a vendor-supported fixed release that includes upstream commit dd1de9268745f0eac83a430db7afc32cbd62e84b or an equivalent backport.
• Reboot patched systems and verify the running kernel is the remediated version.
• Disable ksmbd on systems that do not explicitly require the in-kernel SMB server; use least-exposure network controls for systems that do.
• Restrict SMB access to trusted management, client, or storage networks and block unnecessary inbound TCP/445 exposure.
• Monitor kernel logs and crash telemetry for ksmbd-related faults, especially around SMB session setup activity.
• Treat unexplained kernel crashes on ksmbd file servers as potentially security-relevant until logs and memory/crash artifacts are reviewed.
• Because EPSS is elevated despite no KEV listing, include this vulnerability in near-term Linux kernel patch cycles rather than deferring to routine maintenance.