CVE-2025-39720

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

The vulnerable code is in ksmbd, the in-kernel SMB server listening on TCP/445, and is driven entirely by remote SMB2 CREATE/WRITE/CLOSE traffic and connection teardown. No local access is needed.

AC:LAttack complexity, low

The leak is deterministic, not a race: `ksmbd_conn_set_releasing()` runs before the file table is torn down, so `smb_lazy_parent_lease_break_close()` always sees the connection's own v2 directory-lease opinfo with `conn` already RELEASING. The multi-connection variant against `smb_break_all_levII_oplock()` is also fully attacker-controlled and the window can be widened at will by keeping a request pending.

PR:NPrivileges required, none

ksmbd supports guest/anonymous sessions (`user_guest()`, `SMB2_SESSION_FLAG_IS_GUEST_LE`), so on the guest-mapped shares typical of NAS and embedded deployments an unauthenticated client can open a file with a lease and reach these paths; otherwise only an ordinary unprivileged SMB account is needed.

UI:NUser interaction, none

The attacker triggers everything itself by opening a leased handle and closing the connection; no action by any local user or administrator is involved.

S:UScope, unchanged

The leaked allocations and the resulting exhaustion are confined to the kernel's own memory, the same security authority as the vulnerable ksmbd code. No boundary such as VM or IOMMU is crossed.

C:NConfidentiality impact, none

Nothing is freed early, read out of bounds, or copied to the client; the only effect is that objects are never released. No kernel data or pointer value is exposed.

I:NIntegrity impact, none

No memory is overwritten and no file or kernel state is modified incorrectly; the reference count simply never reaches zero.

A:HAvailability impact, high

Each trigger permanently leaks an `oplock_info`, `lease`, the whole `ksmbd_conn`, the `tcp_transport`/iov, and the accepted TCP socket (since `sock_release()` only runs on the final conn put), and it can be repeated per connection without bound, driving the kernel to unreclaimable memory exhaustion and OOM.