UBUNTU-CVE-2026-98897: Medium severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: ksmbd: don't hold ci->mlock 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 waitforbreakack() for up to OPLOCKWAITTIME (35s). smbbreakalllevIIoplock() runs that wait while holding ci->mlock 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 (closeiddeloplock() -> opinfodel()) takes ci->mlock 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->mlock, then break them after releasing it, matching how smbgrantoplock() 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 OPLOCKCLOSING state check. Apply the same fix to the parent lease break paths.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Update the ksmbd parent lease-break paths so target opinfos are collected and pinned with references while holding ci->m_lock, then ci->m_lock is released before breaking the leases or waiting for the break acknowledgment; apply the same pattern to paths such as __smb_break_all_levII_oplock().
Event History
Frequently Asked Questions
Which systems are exposed to the delay?
The affected path involves a ksmbd server and a cifs.ko client that has cached a read-handle lease through deferred close. A conflicting open must then cause ksmbd to break that lease while leases are enabled.
What behavior indicates this issue is occurring?
Lease-break processing can wait for the full OPLOCK_WAIT_TIME of 35 seconds because the client closes the deferred handle instead of sending a lease-break acknowledgment. In the reported test case, xfstests generic/001 took about 78 seconds with leases enabled, compared with about 4 seconds using oplocks only.