CVE-2024-49988

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 the in-kernel SMB server (fs/smb/server/), driven entirely by SMB2/3 traffic on TCP/445 — the attacker triggers it by opening connections, binding a second channel, dropping the first, and issuing CREATE/WRITE requests that force an oplock/lease break. No local access is needed.

AC:LAttack complexity, low

The attacker controls both sides of the sequence: they create the oplock/lease, they establish and tear down the channel that frees the ksmbd_conn, and they choose when to trigger the break that dereferences the stale pointer, so it is repeatable at will and can be retried indefinitely across connections. Heap grooming to reclaim the freed conn is done with attacker-sent SMB buffers, and the config-independent r_count/RELEASING TOCTOU offers an additional path.

PR:LPrivileges required, low

An authenticated SMB session is required — oplocks/leases are only created after session setup and tree connect, and multichannel binding is explicitly refused for guest users (user_guest() → -EOPNOTSUPP), so valid credentials are needed. No administrative or share-admin privileges are required beyond ordinary file access on an exported share.

UI:NUser interaction, none

The attacker performs every step from its own SMB connections — open with a batch oplock/lease, bind a channel, disconnect it, then re-open or write the file to force the break. No action by an administrator or another user is required.

S:UScope, unchanged

The use-after-free corrupts kernel heap memory belonging to the ksmbd server and is exploited within the kernel's own security authority; no hypervisor, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

The freed struct ksmbd_conn is read back in multiple paths (compare_guid_key reads conn->ClientGUID, ksmbd_conn_write follows conn->transport->ops), so reclaiming the slab object with attacker-shaped data turns these into a kernel-memory read/disclosure primitive, and break notifications built from the stale conn can leak kernel data to the wire.

I:HIntegrity impact, high

The same dangling pointer is written through — atomic_inc/dec on conn->r_count, mutex_lock(&conn->srv_mutex), and wake_up(&conn->r_count_q) traversing a freed waitqueue — and conn->transport->ops->writev is called indirectly, giving controlled-write and control-flow-hijack potential for full kernel compromise.

A:HAvailability impact, high

Dereferencing and writing to the freed ksmbd_conn reliably corrupts the slab and oopses or panics the kernel (mutex/waitqueue operations on freed memory, indirect call through a stale transport pointer), taking down the whole system.