CVE-2026-31477

ksmbd: fix memory leaks and NULL deref in smb2_lock()

7.5 HighFix available

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before the if(!rc) check in the UNLOCK branch so all exit paths share one free site, and by freeing smb_lock and flock before goto out in the non-UNLOCK branch. Propagate the correct error code in both cases. Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding a NULL check for locks_free_lock(rlock) in the shared cleanup.

Found via call-graph analysis using sqry.

Attack profile

How easy it is to exploit

Attack vector: Network
Complexity: Low
Privileges needed: None
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: None
Availability: High

Exploit likelihood

0.48%Up 0.5 points since Apr 23, 2026

What each source reports

CVE List Score used 7.5

ksmbd: fix memory leaks and NULL deref in smb2_lock()

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Found via call-graph analysis using sqry.

Record: CVE-2026-31477
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

EUVDEUVD-2026-24833 7.5

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Found via call-graph analysis using sqry.

Record: EUVD-2026-24833
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

GitHub AdvisoriesGHSA-crxr-hqjj-5w24 7.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memory leaks and...

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Found via call-graph analysis using sqry.

Record: GHSA-crxr-hqjj-5w24
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-476
Updated: 2026-11-02

NVD 7.5

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Found via call-graph analysis using sqry.

Record: CVE-2026-31477
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-476
Updated: 2026-11-02

OSVBELL-CVE-2026-31477 7.5

Record: BELL-CVE-2026-31477
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSV 7.5

ksmbd: fix memory leaks and NULL deref in smb2_lock()

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix memory leaks and NULL deref in smb2_lock()

smb2_lock() has three error handling issues after list_del() detaches smb_lock from lock_list at no_check_cl:

If vfs_lock_file() returns an unexpected error in the non-UNLOCK path, goto out leaks smb_lock and its flock because the out: handler only iterates lock_list and rollback_list, neither of which contains the detached smb_lock.
If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out leaks smb_lock and flock for the same reason. The error code returned to the dispatcher is also stale.
In the rollback path, smb_flock_init() can return NULL on allocation failure. The result is dereferenced unconditionally, causing a kernel NULL pointer dereference. Add a NULL check to prevent the crash and clean up the bookkeeping; the VFS lock itself cannot be rolled back without the allocation and will be released at file or connection teardown.

Found via call-graph analysis using sqry.

Record: CVE-2026-31477
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

Show 22 moreShow less

OSVDEBIAN-CVE-2026-31477 7.5

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

Record: DEBIAN-CVE-2026-31477
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVOESA-2026-2416 8.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix use-after-free in crypt_message when using async crypto

The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:

crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req);

// Async encryption returns -EINPROGRESS immediately
rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);

// Free creq while async operation is still in progress
kvfree_sensitive(creq, ...);

Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.

This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.

The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.

Fix by restoring the async crypto handling:

DECLARE_CRYPTO_WAIT(wait) for completion tracking
aead_request_set_callback() for async completion notification
crypto_wait_req() to wait for operation completion

This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.(CVE-2025-38488)

In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.(CVE-2025-39841)

In the Linux kernel, the following vulnerability has been resolved:

nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()

nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:

[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI:…

Record: OESA-2026-2416
CVSS 3.1: 8.8 HighCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVUBUNTU-CVE-2026-31477 7.1

Record: UBUNTU-CVE-2026-31477
CVSS 4.0: 7.1 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-11

OSVMGASA-2026-0108 No score

Updated kernel, kmod-virtualbox & kmod-xtables-addons packages fix security vulnerabilities

Upstream kernel version 6.6.137 fixes bugs and vulnerabilities. The kmod-virtualbox & kmod-xtables-addons packages have been updated to work with this new kernel.

Record: MGASA-2026-0108
Updated: 2026-11-02

OSVMGASA-2026-0110 No score

Updated kernel-linus packages fix security vulnerabilities

Vanilla upstream kernel version 6.6.137 fixes bugs and vulnerabilities. For information about the vulnerabilities see the links.

Record: MGASA-2026-0110
Updated: 2026-11-02

OSVROOT-OS-DEBIAN-12-CVE-2026-31477 No score

CVE-2026-31477 in linux - Patched by Root

Root has patched CVE-2026-31477 in the linux package for Root:Debian:12. Multiple fixed versions available.

Record: ROOT-OS-DEBIAN-12-CVE-2026-31477
Updated: 2026-11-02

OSVROOT-OS-UBUNTU-2204-CVE-2026-31477 No score

CVE-2026-31477 in linux - Patched by Root

Root has patched CVE-2026-31477 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2204-CVE-2026-31477
Updated: 2026-11-06

OSVROOT-OS-UBUNTU-2404-CVE-2026-31477 No score

CVE-2026-31477 in linux - Patched by Root

Root has patched CVE-2026-31477 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2404-CVE-2026-31477
Updated: 2026-11-06

OSVUSN-8567-1 No score

linux, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-realtime, linux-realtime-6.8 vulnerabilities

It was discovered that some AMD processors did not properly clear data in the floating point divider unit during speculative execution. A local attacker could use this to expose sensitive information. (CVE-2025-54505)

It was discovered that some AMD Zen 2 processors did not properly isolate shared resources in the operation cache. A local attacker could possibly use this issue to corrupt instructions executed at a higher privilege level, resulting in privilege escalation. (CVE-2025-54518)

It was discovered that some AMD Zen 5 processors supporting RDSEED instruction did not properly handle entropy, potentially resulting in the consumption of insufficiently random values. A local attacker could possibly use this issue to influence the values returned by the RDSEED instruction causing loss of confidentiality and integrity. (CVE-2025-62626)