CVEvulnerability

CVE-2026-64396

8.8 HIGH Published 2026-07-25 Modified 2026-09-04 Official page ↗
Status
Analyzed
Published
2026-07-25
Last modified
2026-09-04
Assigner
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS 3.1 (416baaa9-dc9f-4396-8d5f-8c081fb06d67)
8.8 HIGH — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses
CWE-416

Description

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation When a blocking byte-range lock request is deferred in the FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into the connection's async_requests list via setup_async_work(). The cancel callback smb2_remove_blocked_lock() holds a reference to the flock. If the lock waiter is subsequently woken up but the work state is no longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locks_free_lock(flock) without dequeuing the work from the async_requests list. Concurrently, smb2_cancel() walks the list under conn->request_lock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside __wake_up_common. Fix this by restructuring the cleanup logic after the worker returns from ksmbd_vfs_posix_lock_wait(). Move list_del(&smb_lock->llist) and release_async_work(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->request_lock before locks_free_lock(flock) is called, rendering the flock unreachable for any concurrent smb2_cancel().

Affected configurations

• linux linux kernel (>= 5.15 < 6.1.178) • linux linux kernel (>= 6.2 < 6.6.145) • linux linux kernel (>= 6.7 < 6.12.96) • linux linux kernel (>= 6.13 < 6.18.39) • linux linux kernel (>= 6.19 < 7.1.4)

Related

Weakness · CWE (1)

References