CVE-2026-64108

What it actually does

This is a Linux kernel CIFS/SMB client race condition involving deferred file-close work and filesystem unmount handling. Under a specific timing sequence, a CIFS file object can retain a dentry reference after unmount processing has progressed, causing the kernel to detect that a dentry is still in use during superblock shutdown. The upstream fix flushes the CIFS deferred-close workqueue before calling the generic superblock teardown path, ensuring pending close operations release their references before unmount completes. The assigned CVSS vector indicates local exploitation with low privileges and no user interaction, with potential confidentiality, integrity, and availability impact if the race can be turned into memory corruption or kernel-state manipulation rather than only a warning/crash condition.

Why it matters to the business

Systems that mount SMB/CIFS shares from Linux hosts may be exposed to local denial-of-service or, depending on kernel configuration and exploitability, broader kernel compromise risk by a local user or compromised local process. The issue is not known to be exploited in the wild, is not listed in CISA KEV, has very low EPSS at the time of assessment, and has no reported mature public exploit, so urgency is lower than internet-facing remotely exploitable vulnerabilities; however, kernel flaws should still be prioritized on shared servers, multi-user systems, virtualization hosts, build runners, and appliances that use CIFS mounts because successful exploitation may affect the whole host.

How an attack unfolds

An attacker first needs local code execution or an account capable of exercising filesystem operations on a Linux system that uses the CIFS client. The attacker repeatedly opens and closes files on a CIFS-mounted path while concurrently triggering or racing unmount operations. The vulnerable timing occurs when CIFS deferred close work is queued after the file descriptor is closed, but unmount proceeds before that deferred work has released the dentry reference. On affected kernels, this can leave a busy dentry visible during generic superblock shutdown and may produce kernel warnings, instability, or crash behavior. A reliable exploit would automate the open, close, deferred-close, and unmount race at high frequency to increase the chance of hitting the vulnerable interleaving.

How to fix it

Apply a Linux kernel update that includes the CIFS fix to flush the deferred-close workqueue before superblock teardown. Because no exact affected package list or fixed versions were provided, use the corrected kernel packages from the operating system vendor, distribution security channel, appliance vendor, or upstream stable kernel branch once available. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can mount or unmount CIFS filesystems, avoiding untrusted workloads on systems with CIFS mounts, disabling unused CIFS mounts, and using mount management controls so unprivileged users cannot trigger CIFS unmount races.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, contains the CIFS patch. Validate by checking vendor advisories or kernel changelogs for the fix described as flushing deferredclose_wq before kill_anon_super in CIFS unmount handling. On Linux systems, verify the active kernel with commands such as `uname -a` and compare it with the vendor-fixed kernel version. Review whether the host has CIFS/SMB mounts using `/proc/mounts`, `findmnt -t cifs`, or equivalent configuration management data. After patching and rebooting, perform normal CIFS mount, file open/close, and unmount workflows and confirm kernel logs no longer show busy dentry warnings during CIFS unmount.

Typical attack path

1. Obtain local code execution or low-privileged access on a Linux host that has CIFS/SMB client support and mounted CIFS shares.
2. Identify a CIFS-mounted path the user can access or influence.
3. Repeatedly open files on the CIFS mount to create CIFS file structures and dentry references.
4. Close the file descriptors so CIFS deferred-close work is queued.
5. Race the deferred close against unmount or namespace cleanup of the CIFS filesystem.
6. Trigger the vulnerable ordering where unmount reaches superblock shutdown before deferred close releases the dentry reference.
7. Observe kernel warnings, instability, or potential denial-of-service; in a stronger exploit scenario, attempt to shape kernel object lifetime for privilege escalation or kernel memory corruption.

How to detect it

Look for evidence of attempted or accidental triggering in kernel logs and system audit data. Primary sources include `dmesg`, journald kernel facility logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump records, and EDR telemetry for local process activity around CIFS mounts. Search for kernel warnings mentioning busy dentries during CIFS unmount, `generic_shutdown_super`, `shrink_dcache_for_umount`, `umount_check`, or CIFS deferred-close functions. Correlate these events with frequent open/close activity on CIFS-mounted paths and repeated mount or unmount operations by local users, scripts, containers, or services. Also review auditd or equivalent logs for repeated `mount`, `umount`, `umount2`, namespace teardown, or process execution patterns involving CIFS paths. There are no known threat actors or public exploitation campaigns reported for this issue in the supplied data, so detection should focus on kernel artifacts and suspicious local race-triggering behavior rather than known external infrastructure.

• BUG: Dentry
• still in use
• [unmount of cifs cifs]
• generic_shutdown_super
• shrink_dcache_for_umount
• umount_check
• cifs_kill_sb
• cifs_close_all_deferred_files_sb
• cifs_close_all_deferred_files
• smb2_deferred_work_close
• _cifsFileInfo_put
• cifsFileInfo_put_final
• deferredclose_wq
• CIFS VFS
• type=cifs

What your security team should do

• Inventory Linux systems that use CIFS/SMB client mounts, especially shared servers, CI/CD runners, VDI hosts, file-transfer systems, and multi-user compute platforms.
• Track the relevant Linux distribution or vendor advisory and deploy the first fixed kernel package available for each supported platform.
• Prioritize patching systems where untrusted or low-privileged users can run local code and interact with CIFS-mounted paths.
• Reboot systems after kernel updates and verify the fixed kernel is active.
• Restrict CIFS mount and unmount permissions to trusted administrators or controlled service accounts.
• Monitor kernel logs for CIFS unmount warnings, busy dentry messages, kernel BUG/WARN events, and unexpected reboots or panics.
• If suspicious kernel warnings are observed, preserve kernel logs, audit logs, shell history, and workload telemetry before rebooting where operationally feasible.
• Because this is not KEV-listed and has very low EPSS, handle through normal kernel patch management unless affected hosts are multi-tenant or high-value, in which case accelerate remediation.