CVE-2026-64142

Critical · 9.8

CVSS

9.8

EPSS

0.7%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux file-sharing software could let remote attackers crash servers or take control without any login.

Exploitation: Remote Unauthenticated
Attacker needs: None
Complexity: Moderate
Impact: Full Compromise
Component: OS kernel
Class: Use After Free
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

Race conditions in ksmbd_durable_scavenger allow list-head reuse and refcount races against m_fp_list walkers, resulting in use-after-free on durable SMB handles during concurrent lookups such as rename and share-mode checks.

Why it matters to the business

Remote attackers can crash or potentially execute arbitrary code on Linux servers exposing SMB shares via ksmbd, risking data exposure or denial of service; low urgency given absence from known exploitation lists and stable low exploit probability.

How an attack unfolds

An unauthenticated network attacker opens an SMB2 session requesting a durable handle, tears down the session to preserve the handle on the list, then issues concurrent rename or permission-check operations while the scavenger thread expires and frees the handle, triggering the use-after-free.

How to fix it

Apply the upstream kernel patch that stops fp-node reuse, adds transient references, clears persistent_id immediately after idr_remove, and guards open_files_count decrements; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Boot with CONFIG_DEBUG_LIST and KASAN enabled, then run concurrent SMB2 durable-handle workloads that exercise ksmbd_lookup_fd_inode and ksmbd_durable_scavenger; confirm absence of list corruption, KASAN reports, and UAF warnings.

Typical attack path

Connect to ksmbd over SMB2 and request a durable handle
Close the session while preserving the durable entry on m_fp_list
Trigger concurrent operations (rename or share checks) that walk m_fp_list
Time the scavenger to expire and free the handle during the walk
Read or write through the dangling reference to achieve UAF

How to detect it

Inspect kernel logs for CONFIG_DEBUG_LIST warnings, KASAN use-after-free reports, or oops traces mentioning ksmbd_durable_scavenger, m_fp_list, or ksmbd_lookup_fd_inode during SMB activity.

What your security team should do

Prioritize kernel updates containing the ksmbd scavenger fix on all systems exposing SMB shares
Temporarily disable ksmbd (or block SMB ports) on internet-facing systems until patched
Add kernel crash and KASAN monitoring to detect attempted exploitation
Review SMB exposure and restrict durable-handle usage where possible

The record

In the Linux kernel, the following vulnerability has been resolved: ksmbd: close durable scavenger races against m_fp_list lookups ksmbd_durable_scavenger() has two related races against any walker that iterates f_ci->m_fp_list, including ksmbd_lookup_fd_inode() (used by ksmbd_vfs_rename) and the share-mode checks in fs/smb/server/smb_common.c. (1) fp->node list-head reuse. Durable-preserved handles can remain linked on f_ci->m_fp_list after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavenger_list after removing them from the global durable idr. Because fp->node is the same list_head used by m_fp_list, list_add(&fp->node, &scavenger_list) overwrites the m_fp_list links and corrupts both lists. CONFIG_DEBUG_LIST can report this on the share-mode walk path. (2) Refcount race against m_fp_list walkers. The scavenger qualifies an expired durable handle with atomic_read(&fp->refcount) > 1 and fp->conn under global_ft.lock, removes fp from global_ft, then drops global_ft.lock before unlinking fp from m_fp_list and freeing it. During that gap fp is still linked on m_fp_list with f_state == FP_INITED. ksmbd_lookup_fd_inode() under m_lock read calls ksmbd_fp_get() (atomic_inc_not_zero on refcount that is still 1) and takes a live reference; the scavenger then unlinks and frees fp while the holder owns a reference, leading to UAF on the holder's subsequent ksmbd_fd_put() and on any field reads performed by a concurrent share-mode walker that iterates m_fp_list without taking ksmbd_fp_get() (smb_check_perm_dleases-like paths). Fix both: * Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from global_ft under global_ft.lock, take an explicit transient reference, drop the lock, unlink fp->node from m_fp_list under f_ci->m_lock, then drop both the durable lifetime and transient references with atomic_sub_and_test(2, &fp->refcount). If the scavenger is the last putter the close runs there; otherwise an in-flight holder that already raced through the m_fp_list lookup owns the final close via its ksmbd_fd_put() path. The one-at-a-time disposal can rescan the durable idr when multiple handles expire in the same pass, but durable scavenging is a background expiration path and the final full scan recomputes min_timeout before the next wait. * Clear fp->persistent_id inside __ksmbd_remove_durable_fd() right after idr_remove(), so a delayed final close from a holder that snatched fp does not re-issue idr_remove() on a persistent id that idr_alloc_cyclic() in ksmbd_open_durable_fd() may have already handed out to a brand-new durable handle. * Bypass the per-conn open_files_count decrement in __put_fd_final() when fp is detached from any session table (fp->conn cleared by session_fd_check() at durable preserve -- paired with the volatile_id clear at unpublish, so checking fp->conn alone is sufficient). The walker that owns the final close runs from an unrelated work->conn whose stats.open_files_count never tracked this durable fp; without this guard the holder would underflow that unrelated counter. The two races are folded into one patch because patch (1) alone cleans up the corrupted list but leaves a deterministic UAF window for m_fp_list walkers that the transient-reference and persistent_id discipline in (2) close; bisecting onto an intermediate state would land on a UAF that pre-patch chaos merely made less reproducible. Validation: * CONFIG_DEBUG_LIST coverage for the list_head reuse path. * KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbd_durable_scavenger() and non-NULL ksmbd_lookup_fd_inode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. ---truncated---

Affected packages

Ecosystem	Package	Introduced	Fixed