---
id: "CVE-2026-99276"
page: "https://infrastack.ai/live/CVE-2026-99276"
kind: "vulnerability"
aliases: ["CVE-2026-99276"]
title: "Linux kernel ksmbd: lock ordering flaw can stall SMB connection scavenging"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["file-server", "kernel", "ksmbd", "linux", "runtime", "smb"]
not_affected_if: ["ksmbd-not-loaded"]
published_at: "2026-11-07T14:17:02+00:00"
first_seen_at: "2026-11-07T14:47:40+00:00"
updated_at: "2026-11-07T14:49:53+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99276", "first_seen_at": "2026-11-07T14:47:40+00:00"}]
exploit_sources: []
---

# Linux kernel ksmbd: lock ordering flaw can stall SMB connection scavenging

Link for people: https://infrastack.ai/live/CVE-2026-99276 (this .md is for agents)

A lock-ordering problem in the Linux kernel's ksmbd SMB server can cause the connection expiration worker to deadlock against session teardown. The sources do not state what an attacker gains beyond disrupting the SMB server.

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

## How to check

- Check the kernel version with `uname -r` and whether the ksmbd module is loaded with `lsmod | grep ksmbd`

## Timeline

- 2026-11-07T14:47:40+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99276

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: defer connection scavenging while session locks are busy

The expiration worker holds conn_list_lock for reading while checking
for authenticated sessions. Without this change, the check can wait for
conn->session_lock or sessions_table_lock.

In destroy_previous_session(), the status updates after
ksmbd_conn_wait_idle_sess() run with both session locks held for
writing. Both the KSMBD_SESS_GOOD error path and the
KSMBD_SESS_NEED_SETUP success path call ksmbd_all_conn_set_status(),
which takes conn_list_lock for reading.

A writer queued on conn_list_lock can block these new read acquisitions.
The worker then waits for a session lock held by
destroy_previous_session(), which waits behind the writer. The writer
cannot proceed until the worker releases conn_list_lock.

Try both session locks instead of waiting in the scavenging check. Keep
the connection when either lock is busy and let the periodic worker
retry later.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_