CVE-2026-45924

What it actually does

This flaw is a Linux kernel ksmbd defect in error-path cleanup during SMB server file-removal handling. When ksmbd_vfs_kern_path_start_removing() succeeds but later processing fails, some paths do not call the matching ksmbd_vfs_kern_path_end_removing(), leaving inode locks, superblock writer state, and object references unbalanced. The resulting leaked locks can stall ksmbd worker threads, trigger kernel lock-debug warnings such as “BUG: workqueue leaked lock or atomic,” and potentially cause local denial of service through hung SMB operations or broader filesystem availability degradation. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, and high availability impact; it does not indicate confidentiality or integrity compromise.

Why it matters to the business

Systems using the in-kernel Linux SMB server may experience hangs, degraded file-share availability, or service interruption if a local low-privileged user can trigger the vulnerable path. The main operational risk is downtime for SMB-backed file sharing, backup jobs, application workflows, or storage services that depend on ksmbd. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no public exploit maturity reported, so prioritization should be driven by exposure of ksmbd-enabled systems and the importance of uninterrupted file-share availability.

How an attack unfolds

An attacker first needs local low-privileged access to a Linux system running a vulnerable kernel with ksmbd enabled. The attacker then performs file or directory removal-related operations that enter ksmbd’s VFS path-removal logic and deliberately cause an error after ksmbd_vfs_kern_path_start_removing() has acquired locks and references. Because affected kernels fail to call ksmbd_vfs_kern_path_end_removing() on specific error paths, those locks and references may remain held. Repeated triggering can exhaust or stall ksmbd worker processing, leave filesystem locks in an inconsistent state, and produce kernel warnings about leaked locks or atomic context from handle_ksmbd_work. The expected attacker outcome is denial of service rather than data theft or code execution.

How to fix it

Upgrade to a Linux kernel build that includes the ksmbd fix ensuring ksmbd_vfs_kern_path_end_removing() is called on all relevant error paths. No exact fixed version was provided in the input, so use the patched kernel packages supplied by the operating system vendor or upstream stable kernel branch for the deployed distribution. If immediate patching is not possible, reduce exposure by disabling ksmbd where it is not required, replacing in-kernel SMB service with a supported alternative where appropriate, limiting local shell access to trusted users, and restricting SMB share access to authorized users and networks. Because this is a kernel flaw, remediation normally requires installing the updated kernel and rebooting into it.

How to confirm the fix worked

Confirm that systems are no longer running an affected kernel package and have rebooted into the patched kernel, not merely installed it. Verify ksmbd status with service/module checks such as whether the ksmbd service is active or the ksmbd kernel module is loaded. Review vendor advisories for the exact fixed kernel package version applicable to each distribution. After patching, exercise normal SMB file create, rename, and delete workflows and confirm there are no new kernel messages showing leaked locks, hung ksmbd workers, or lockdep warnings. On systems where ksmbd is not required, validate that the service is stopped, disabled, and the module is not loaded.

Typical attack path

1. Obtain local low-privileged access to a Linux host running an affected kernel.
2. Confirm that the in-kernel SMB server, ksmbd, is loaded or active.
3. Interact with SMB-shared files or directories in a way that reaches removal/rename/unlink error-handling paths.
4. Trigger error conditions after ksmbd_vfs_kern_path_start_removing() has acquired inode and superblock writer locks.
5. Repeat the operation to increase the chance of leaked locks, stalled ksmbd worker threads, or filesystem operation hangs.
6. Cause SMB file-share degradation or denial of service, potentially requiring service restart or host reboot to recover.

How to detect it

To determine whether this vulnerability may already have been triggered, review kernel logs, system journal entries, and crash/hung-task diagnostics from systems running ksmbd. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, audit logs for local user activity, and any EDR telemetry that captures kernel warnings or service hangs. Look for lockdep or workqueue warnings involving handle_ksmbd_work, ksmbd-io, kworker threads, leaked locks, atomic-context warnings, sb_writers locks, inode mutexes, or ksmbd VFS path-removal functions. Correlate those messages with spikes in failed SMB delete/rename/unlink operations, SMB client disconnects, ksmbd service instability, hung tasks, or unexplained file-share outages. Because no public exploit indicators or named threat actors are known from the provided data, detection should focus on behavioral evidence of repeated error-path triggering and ksmbd-related kernel lock warnings rather than fixed external IOCs.

• BUG: workqueue leaked lock or atomic
• last function: handle_ksmbd_work
• Workqueue: ksmbd-io handle_ksmbd_work
• ksmbd_vfs_kern_path_locked
• ksmbd_vfs_kern_path_start_removing
• ksmbd_vfs_kern_path_end_removing
• sb_writers#3
• i_mutex_dir_key
• Comm: kworker
• hung task
• ksmbd

What your security team should do

• Inventory Linux systems that run ksmbd or expose in-kernel SMB file sharing, and prioritize those supporting business-critical file shares.
• Apply vendor kernel updates that contain the ksmbd cleanup fix, then reboot and verify the running kernel version.
• If patching is delayed, disable ksmbd on systems that do not explicitly require it or restrict access to trusted users and management networks.
• Limit local account access because the CVSS vector requires local low-privileged access.
• Monitor kernel logs for ksmbd worker lock leaks, hung tasks, and filesystem lock warnings that may indicate attempted triggering or operational impact.
• Treat repeated ksmbd-related kernel warnings on file servers as an availability incident and collect forensic logs before rebooting where feasible.
• Track Linux distribution advisories for exact backported fixed package versions, since upstream kernel fixes may appear under distribution-specific release numbers.