CVE-2026-68381

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 listening on TCP/445 (and SMB-Direct); the oplock/lease break notification path is driven entirely by remote SMB2 CREATE/close traffic and connection teardown, so a remote peer reaches the freed-conn use over the network.

AC:LAttack complexity, low

The attacker controls both sides of the race: one connection holds a batch oplock/lease while a second connection opens the same file to force the async break, and the first connection is then abruptly dropped so teardown passes the r_count wait before the increment lands; this can be retried across arbitrarily many connections.

PR:NPrivileges required, none

ksmbd share access is commonly exposed with guest/anonymous mapping, so an unauthenticated or trivially-credentialed remote client can open files and trigger oplock/lease breaks; consistent with prior ksmbd connection-lifetime UAF scoring, no meaningful privilege gate protects this path.

UI:NUser interaction, none

No victim action is needed; the attacker's own two SMB connections create the oplock break and the racing disconnect entirely on their own initiative.

S:UScope, unchanged

The freed object and the corrupted state are both kernel memory owned by the ksmbd server within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

Use-after-free of struct ksmbd_conn lets the attacker reclaim the slab object with attacker-shaped data and have the worker read conn->transport and response state from it, enabling disclosure of kernel memory and pointer values, potentially leaked back over the SMB connection.

I:HIntegrity impact, high

ksmbd_conn_write() dereferences conn->transport->ops->writev from the freed object and indirectly calls it, and ksmbd_conn_lock()/ksmbd_conn_r_count_dec() perform mutex and atomic/waitqueue writes into freed memory, giving heap-spray-based control-flow hijack and arbitrary-write potential.

A:HAvailability impact, high

Even without successful exploitation, using a freed ksmbd_conn (mutex operations, transport pointer dereference, waitqueue wakeup) reliably causes memory corruption, oops, or kernel panic, taking down the whole system.