Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2026-64396

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
25/07/2026
Última modificación:
25/07/2026

Descripción

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

Impacto