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

CVE-2026-31477

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

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix memory leaks and NULL deref in smb2_lock()<br /> <br /> smb2_lock() has three error handling issues after list_del() detaches<br /> smb_lock from lock_list at no_check_cl:<br /> <br /> 1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK<br /> path, goto out leaks smb_lock and its flock because the out:<br /> handler only iterates lock_list and rollback_list, neither of<br /> which contains the detached smb_lock.<br /> <br /> 2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out<br /> leaks smb_lock and flock for the same reason. The error code<br /> returned to the dispatcher is also stale.<br /> <br /> 3) In the rollback path, smb_flock_init() can return NULL on<br /> allocation failure. The result is dereferenced unconditionally,<br /> causing a kernel NULL pointer dereference. Add a NULL check to<br /> prevent the crash and clean up the bookkeeping; the VFS lock<br /> itself cannot be rolled back without the allocation and will be<br /> released at file or connection teardown.<br /> <br /> Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before<br /> the if(!rc) check in the UNLOCK branch so all exit paths share one<br /> free site, and by freeing smb_lock and flock before goto out in the<br /> non-UNLOCK branch. Propagate the correct error code in both cases.<br /> Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding<br /> a NULL check for locks_free_lock(rlock) in the shared cleanup.<br /> <br /> Found via call-graph analysis using sqry.

Impacto