Look up another CVE · open CVE-2026-80926 in the interactive tracker

CVE-2026-80926

ksmbd: fix use-after-free in oplock break notification

9.8 EPSS 0.4% AV:N

Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem fs/smb. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-80926 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	fixedDSA-6528-1 · 2026-09-29 · text	6.12.111-1	Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.2.6-1	Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4817-1 · 2026-10-04 · text	6.12.111-1~deb12u1	Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

smb2_oplock_break_noti() reads opinfo->conn without any lock and dereferences it after two allocations which may sleep. When the durable handle owning the oplock is disconnected, session_fd_check() clears opinfo->conn and drops its conn reference under ci->m_lock, and the last ksmbd_conn_put() frees the connection. A break triggered by another connection that races with the teardown can then resurrect the freed connection: ksmbd_conn_get() is a plain atomic_inc, and the queued break work later dereferences the stale conn via ksmbd_conn_write(), a use-after-free reachable by any authenticated client holding a durable batch oplock. Thread the caller's inode into the notification path instead of taking a new reference on it. Every caller of oplock_break() already holds a live ksmbd_file (or an explicit ksmbd_inode_lookup_lock() reference, in the parent lease break paths) on the inode that owns the break target's oplock list, so ci cannot be freed during the call, and its lock can be taken without dereferencing opinfo->o_fp, which a concurrent close may free. Select and pin the connection under ci->m_lock, the same lock session_fd_check() and ksmbd_reopen_durable_fd() use to update opinfo->conn, so a concurrent detach either loses the race to the clear or keeps the connection alive until the notification work releases it. Transfer the reference to the work item and release it on allocation failures.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

fs/smb/server/oplock.c

What this is: KERNEL SMB3 SERVER (KSMBD)MAINTAINERS section matched on fs/smb/server/ · linux-cifs@vger.kernel.org · Maintained
Kernel module: ksmbd

Check it on the machine

grep -wE 'CONFIG_SMBFS|CONFIG_SMB_SERVER' /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w ksmbd

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sid, bookworm · linux-6.12m

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switches: CONFIG_SMBFS, CONFIG_SMB_SERVER
Reads as: all on means the file is compiled; any one off means it is not.

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-09-11 (37 days ago)source
CVSS: 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: network (AV:N)source
EPSS: 0.44%, higher than 37.2% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
Subsystem: fs/smb

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.6.143	6.6.158	892f643b141a
6.12.94	6.12.111	5de0527f7824
6.18.36	6.18.51	c8279ae8df68
7.1	7.2.5	8cc98db4fc59
7.1	7.3	0e753899627b
7.0.13	0	0

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4817-1	2026-10-04	bookworm 6.12.111-1~deb12u1	tracker
DSA-6528-1	2026-09-29	trixie 6.12.111-1	tracker

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:NAttack vector, network: ksmbd is the in-kernel SMB server on TCP/445; smb2_oplock_break_noti() is reached from remote SMB2 CREATE/WRITE/truncate that breaks a durable batch oplock, and the racing teardown is a remote disconnect or SMB2 LOGOFF, so a network peer fully drives the UAF.
AC:LAttack complexity, low: The attacker controls both sides of the race: one connection holds a durable batch oplock while a second opens the same file to force oplock_break(), and dropping the first connection runs session_fd_check() during the sleeping allocations before ksmbd_conn_get(); the window is retryable.
PR:NPrivileges required, none: ksmbd shares are commonly exposed with guest/anonymous mapping, so a remote client can SESSION_SETUP, TREE_CONNECT, CREATE a durable batch oplock, and trigger the racing disconnect without a privileged host account; no meaningful credential gate protects this path.
UI:NUser interaction, none: No victim action is required; the attacker opens both SMB connections, requests the durable batch oplock, forces the conflicting open, and drops the first connection entirely on their own.
S:UScope, unchanged: The freed ksmbd_conn and resulting kernel heap corruption stay within the ksmbd/kernel security authority on the SMB server host; this is not a VM, IOMMU, or sandbox escape.
C:HConfidentiality impact, high: Use-after-free of struct ksmbd_conn lets the attacker reclaim the slab object; __smb2_oplock_break_noti() then reads conn->transport and related fields from attacker-controlled memory, enabling kernel pointer and data disclosure.
I:HIntegrity impact, high: ksmbd_conn_write() calls conn->transport->ops->writev and ksmbd_conn_lock() on the freed object, so heap spraying the reclaimed ksmbd_conn yields an arbitrary function-pointer call and mutex writes into attacker-chosen memory.
A:HAvailability impact, high: Even without a fully controlled exploit, using a freed ksmbd_conn (mutex lock, transport dereference, r_count/waitqueue) causes kernel memory corruption, oops, or panic and takes down the host.