CVE-2026-64400

What it actually does

This is a path traversal bypass in the Linux kernel SMB server, ksmbd. ksmbd normally uses LOOKUP_BENEATH to keep SMB path resolution inside the exported share root. When a crafted path containing parent-directory components attempts to escape the share, the kernel returns -EXDEV, but vulnerable code in caseless lookup mode incorrectly treats that failure like a missing-file condition and retries path resolution. The retry can reconstruct the path in a way that bypasses the share boundary. Successful exploitation can allow a network-accessible SMB user with write capability, including guest or anonymous access where enabled, to create zero-length files or directories outside the intended SMB share root. The described primitive is limited to creation of empty files/directories, but because it crosses an enforced filesystem boundary inside the kernel SMB service, it can affect filesystem integrity and availability.

Why it matters to the business

Organizations using ksmbd to expose SMB file shares may have an unintended write path outside the configured share boundary. In practical terms, an attacker could place files or directories where administrators did not intend SMB users to write, potentially disrupting services, polluting system or application directories, interfering with backups or file-processing workflows, or violating data boundary assumptions. The issue is network-reachable and low-complexity, but it is not currently listed in CISA KEV, is not reported as ransomware-used, has low EPSS at 0.00357, and has no known public exploit maturity in the provided data. Because it affects kernel-level file-sharing behavior, internet-exposed or guest-writable ksmbd deployments should still be treated as high priority.

How an attack unfolds

An attacker first identifies an SMB service backed by Linux ksmbd and locates a writable share. If anonymous or guest write access is enabled, no meaningful credentials may be required; otherwise the attacker uses any account with write permission to the share. The attacker then submits SMB create or mkdir operations using crafted paths that include parent-directory traversal components, such as '..', combined with case variations intended to trigger ksmbd's caseless lookup retry path. The initial protected lookup detects the escape attempt and returns -EXDEV, but vulnerable kernels do not stop there. Instead, they fall through into retry logic intended only for genuinely missing files. During that retry, path reconstruction can bypass the LOOKUP_BENEATH boundary and cause ksmbd to create an empty file or directory outside the exported share root. The attacker can repeat this to plant marker files, create directory structures, consume filesystem resources, or interfere with paths used by other services.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the ksmbd fix restricting caseless lookup retry to -ENOENT only. No exact fixed package versions were provided, so use vendor advisories, kernel changelogs, and package metadata to identify the first fixed kernel for each supported platform. Reboot into the fixed kernel after installation. Where immediate patching is not possible, reduce exposure by disabling ksmbd if it is not required, blocking SMB access from untrusted networks, removing guest or anonymous write access, limiting write permissions to trusted accounts, and avoiding writable shares whose parent directories contain sensitive system or application paths. Consider using compensating controls such as host firewalls, network segmentation, SELinux/AppArmor policy, and filesystem permission hardening to limit the impact of writes outside intended share roots.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the ksmbd caseless retry path traversal issue, not merely that the package is installed. Validate with the running kernel version, distribution security advisory status, and kernel changelog references to the ksmbd fix. Check whether ksmbd is loaded or active using service, module, or process inspection, and verify that SMB port 445 is not exposed beyond intended networks. Review share configurations for caseless behavior and writable access, especially guest-writable shares. In a controlled test environment only, attempt to create a file or directory through an SMB share using parent-directory traversal plus case variation; a fixed system should reject the operation and should not create anything outside the share root. Also verify that filesystem locations adjacent to share roots contain no unexpected zero-length files or directories created during prior exposure.

Typical attack path

1. Scan for SMB services and identify Linux ksmbd-backed file shares.
2. Authenticate to a writable share, or use guest/anonymous access if write permissions are allowed.
3. Submit crafted SMB create or directory-create requests containing parent-directory traversal components such as '..' or '..\\'.
4. Use path casing variations to trigger caseless lookup retry behavior.
5. Cause vulnerable ksmbd path resolution to bypass the share-root LOOKUP_BENEATH restriction.
6. Create zero-length files or directories outside the exported share boundary.
7. Repeat creation attempts to disrupt services, pollute filesystem locations, or establish evidence of unauthorized filesystem access.

How to detect it

Look for evidence of attempted SMB path traversal and unexpected filesystem object creation outside configured ksmbd share roots. Useful sources include ksmbd/kernel logs, systemd journal entries, auditd file creation events, endpoint file integrity monitoring, SMB server telemetry, network IDS/packet captures for SMB create requests, and filesystem metadata around directories adjacent to exported shares. Focus on the period since publication and any earlier exposure window if ksmbd was internet-facing or guest-writable. Hunt for SMB file create or mkdir operations containing '../' or '..\\', unusual case-mismatched path components, repeated create failures followed by successful creates, and newly created zero-byte files or empty directories outside the intended share root owned by the ksmbd process context or SMB user mappings. Because the vulnerability may not produce a unique log message, absence of a clear ksmbd error is not proof of non-exploitation; correlate file creation timestamps, SMB authentication/session records, source IPs, and share write events. If auditd was enabled, search for creat, openat, mkdir, and mknod activity by ksmbd-related processes that targets paths outside exported share directories.

• ../
• ..\\
• ksmbd
• LOOKUP_BENEATH
• -EXDEV
• caseless retry
• vfs_path_parent_lookup
• ksmbd_vfs_path_lookup
• __ksmbd_vfs_kern_path
• type=SYSCALL msg=audit
• syscall=creat
• syscall=openat
• syscall=mkdir
• comm="ksmbd"
• exe="/usr/sbin/ksmbd.mountd"
• kernel: ksmbd

What your security team should do

• Prioritize patching Linux systems that run ksmbd and expose writable SMB shares, especially any reachable from untrusted networks.
• Inventory SMB servers and distinguish kernel ksmbd deployments from user-space Samba deployments, because this issue is specific to ksmbd.
• Disable ksmbd where it is not explicitly required, or restrict SMB access to trusted management and user networks only.
• Remove guest and anonymous write access from SMB shares and review all writable share permissions for least privilege.
• Review filesystem paths outside ksmbd share roots for unexpected zero-byte files or newly created directories around the exposure window.
• Add monitoring for SMB path traversal attempts containing '../' or '..\\' in file operation telemetry where available.
• Confirm after remediation that systems have rebooted into the fixed kernel and are not still running a vulnerable kernel image.