---
id: "CVE-2026-98897"
kind: "vulnerability"
aliases: ["CVE-2026-98897"]
title: "Linux ksmbd: lease break waits block file closes, causing 35-second stalls"
severity: "unknown"
cvss: null
epss: 0.00198
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["ksmbd", "linux-kernel", "runtime", "self-hosted", "smb-server"]
not_affected_if: ["ksmbd-not-enabled"]
published_at: "2026-10-23T12:18:23+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98897", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-98897", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux ksmbd: lease break waits block file closes, causing 35-second stalls

In the Linux kernel's ksmbd SMB server, a lease break waited for an acknowledgment while holding a lock that the close path needed, so closes stalled until a 35-second timeout. The sources describe a performance and availability defect rather than a code execution or data exposure path.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update to a Linux kernel release that includes the upstream commit titled 'ksmbd: don't hold ci->m_lock while waiting for a lease break ack'; the sources do not name the fixed kernel version.

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98897
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-98897

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_