CVE-2026-98897 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: don't hold ci->m_lock while waiting for a lease break ack
When a cifs.ko client caches a read-handle (RH) lease via deferred close and a conflicting open arrives, ksmbd breaks the lease and waits for the acknowledgment in wait_for_break_ack() for up to OPLOCK_WAIT_TIME (35s). __smb_break_all_levII_oplock() runs that wait while holding ci->m_lock for read.
cifs.ko reacts to a handle-lease break by closing the deferred handle rather than sending a lease break acknowledgment. That close path (close_id_del_oplock() -> opinfo_del()) takes ci->m_lock for write and is exactly what would wake the waiter, but it blocks on the read lock held by the waiting thread. The break is then resolved only by the 35s timeout, so xfstests generic/001 takes ~78s with leases enabled versus ~4s with oplocks only.
Collect the target opinfos (each pinned with a reference) while holding ci->m_lock, then break them after releasing it, matching how smb_grant_oplock() already breaks a conflicting lease using only a reference. The reference keeps the opinfo (and its conn and lease) alive across the unlocked window, and a close racing the break is handled by the existing OPLOCK_CLOSING state check. Apply the same fix to the parent lease break paths.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the Linux kernel's ksmbd component centers on a lock contention issue that leads to significant performance degradation rather than a traditional security breach such as data exfiltration or privilege escalation. The core technical flaw resides within the mechanism used by ksmbd to manage SMB leases, specifically when handling conflicting open requests against cached read-handle leases via deferred close operations. When a cifs.ko client holds a lease and a new request arrives that conflicts with it, ksmbd initiates a lease break sequence. This process involves calling wait_for_break_ack(), which waits for an acknowledgment from the client for up to thirty-five seconds while holding ci->m_lock in read mode. The expectation is that the client will respond promptly, but due to specific locking interactions within the kernel's CIFS implementation, this response path becomes blocked.
The operational impact stems from a deadlock-like scenario caused by inconsistent lock ordering and contention between reader-writer locks. When cifs.ko receives the lease break notification, it does not send an immediate acknowledgment; instead, it proceeds to close the deferred handle through the close_id_del_oplock() function chain leading into opinfo_del(). This closure path attempts to acquire ci->m_lock for writing in order to modify connection state information. However, because ksmbd is already holding that same lock in read mode while waiting inside wait_for_break_ack(), the write acquisition by cifs.ko blocks indefinitely until the reader releases the lock. Since the waiter holds the lock and waits for a signal from the writer, neither can proceed, resulting in a livelock situation where progress is halted solely due to locking granularity issues rather than resource exhaustion or malicious input.
This technical flaw manifests as severe latency spikes during file operations that involve lease breaks. In practical testing scenarios using xfstests generic/001, which exercises these specific code paths with leases enabled, the operation time balloons from approximately four seconds under standard oplock handling to nearly seventy-eight seconds when this race condition is triggered. This represents a denial of service effect characterized by extreme latency rather than system crash or data corruption. The prolonged wait times degrade user experience and can cause timeouts in higher-level applications relying on timely SMB responses, effectively rendering the file sharing service unresponsive for affected sessions during these intervals.
The resolution involves restructuring the locking strategy to eliminate the window where a read lock is held while waiting for an external event that requires write access from another thread. The fix dictates collecting target opinfo structures while holding ci->m_lock but then releasing the lock before initiating the actual lease break operations. By pinning references to these objects, ksmbd ensures they remain valid even after the lock is released, allowing subsequent close operations racing against the break to be handled safely via existing state checks like OPLOCK_CLOSING without requiring additional locks that would cause contention. This approach aligns with established patterns in smb_grant_oplock(), which already manages conflicting leases using references rather than holding locks throughout the entire process.
From a vulnerability classification perspective, this issue maps closely to CWE-830, Inclusion of Functionality from Untrusted Control Areas, specifically regarding improper handling of synchronization primitives leading to performance degradation or denial of service conditions often categorized under CWE-400, Uncontrolled Resource Consumption due to locking inefficiencies. While not exploitable for remote code execution, the behavior aligns with ATT&CK techniques related to resource hijacking where system resources are consumed inefficiently through poor concurrency control. Mitigation strategies primarily involve applying the kernel patch that corrects the lock ordering and reference counting logic in ksmbd. Administrators should ensure their systems are updated with the latest stable kernel versions containing this fix, as no user-space configuration changes can resolve the underlying locking race condition within the kernel module itself.