high CVSS 8.8

CVE-2026-64437·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then SMB2_CANCEL Commit f580d27e8928 ("ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL") made smb2_cancel() skip a work whose state is KSMBD_WORK_CANCELLED, so its cancel_fn cannot be fired a second time. But KSMBD_WORK has three states (ACTIVE, CANCELLED, CLOSED), and the same freeing producer path is reached for CLOSED too: SMB2_CLOSE on the locking handle -> set_close_state_blocked_works() sets the deferred work's state to KSMBD_WORK_CLOSED and wakes the smb2_lock() worker. The worker takes the non-ACTIVE early-exit, locks_free_lock()s the file_lock and, because the state is not KSMBD_WORK_CANCELLED, takes the STATUS_RANGE_NOT_LOCKED branch with "goto out2" -- which, like the cancelled branch, skips release_async_work(). The work stays on conn->async_requests with a live cancel_fn = smb2_remove_blocked_lock pointing at the freed file_lock. A subsequent SMB2_CANCEL for the same AsyncId then passes the KSMBD_WORK_CANCELLED-only guard (its state is KSMBD_WORK_CLOSED), so smb2_cancel() fires cancel_fn again over the freed file_lock -- the same use-after-free fixed, via SMB2_CLOSE instead of a first SMB2_CANCEL: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (non-ACTIVE early-exit) ... cache file_lock_cache of size 192 Reproduced on mainline 7.1-rc7 (which already contains f580d27e8928) with KASAN by an authenticated SMB client; the double-SMB2_CANCEL control is silent on that kernel, so the splat is attributable to the CLOSE trigger. Only an ACTIVE deferred work may have its cancel_fn fired: both terminal states (CANCELLED and CLOSED) reach the smb2_lock() early-exit that frees the file_lock and skips release_async_work(). Guard on KSMBD_WORK_ACTIVE so any non-active work is skipped.

Severity
high
Software
Kernel
Fixed in
7.1.4
Published
2026-07-25

Affected versions

From: 7.1.1

Until: 7.1.4

Fixed in: 7.1.4

How to fix this CVE

Update your Linux kernel to version 7.1.4 or later to resolve a use-after-free vulnerability in ksmbd's file locking mechanism. This flaw allows authenticated attackers to trigger memory corruption through a sequence of SMB2 operations (CLOSE followed by CANCEL). Apply the patch immediately on systems running kernels 7.1.1 through 7.1.3 that have ksmbd enabled.

sudo dnf update kernel

Defensia detects this vulnerability

How to check if you are affected

  1. Check installed kernel version: uname -r
  2. Verify ksmbd module is loaded: lsmod | grep ksmbd
  3. List active SMB/CIFS shares: smbclient -L localhost -U%
  4. Search system logs for ksmbd errors: grep -i 'ksmbd\|slab-use-after-free' /var/log/kern.log /var/log/messages
  5. Confirm patch applied: grep 'KSMBD_WORK_ACTIVE' /boot/config-$(uname -r) or check kernel git log for commits 10f293a07f9e or 12c36c99655f3

FAQ

What is CVE-2026-64437?

This is a use-after-free vulnerability in the Linux kernel's ksmbd SMB server implementation. An authenticated attacker can trigger the flaw by closing a file with an active lock, then sending a CANCEL request, causing the kernel to access freed memory and potentially execute arbitrary code with kernel privileges.

Is CVE-2026-64437 being actively exploited?

No, this vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public exploits are currently available. However, it requires only SMB authentication and basic protocol knowledge, so exploitation risk remains moderate for exposed systems.

What versions of Kernel are affected by CVE-2026-64437?

Linux kernel versions 7.1.1, 7.1.2, and 7.1.3 are vulnerable. Version 7.1.4 and later contain the fix. Systems running older 7.0.x kernels or newer 7.2+ releases are not affected.

How do I check if my server is vulnerable to CVE-2026-64437?

Run 'uname -r' to get your kernel version. If it shows 7.1.1, 7.1.2, or 7.1.3, you are vulnerable. Also verify ksmbd is enabled with 'lsmod | grep ksmbd' — if the module is not present, the attack surface is eliminated.

Does Defensia detect CVE-2026-64437?

Yes — Defensia's CVE advisory scanner compares installed kernel package versions against the NVD database. If your Linux kernel is running version 7.1.1–7.1.3, CVE-2026-64437 will appear in your Defensia dashboard with remediation steps and patch recommendations.

Related Kernel CVEs

CVE-2026-64056CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.
CVE-2026-64047CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this: struct sk_msg_sg { [...] /* The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. */ struct scatterlist data[MAX_MSG_FRAGS + 2]; The current code uses MAX_SKB_FRAGS + 1 as the ring size: sg_chain(&msg_pl->sg.data[msg_pl->sg.start], MAX_SKB_FRAGS - msg_pl->sg.start + 1, msg_pl->sg.data); This places the chain pointer at sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS] instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down") Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).
CVE-2026-64055CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Carry over frag counter The gmac_rx() NAPI poll function assembles packets in an SKB from a ring buffer. If the ring buffer gets completely emptied during a poll cycle, we exit gmac_rx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter frag_nr is reset to zero on the next invocation. Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations. Reset the fragment counter only right after calling napi_gro_frags(), on error (after calling napi_free_frags()) or if stopping the port. Reset it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review.
CVE-2026-64383CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_flush() replay SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time. Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.
CVE-2026-64355CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-64437. Free for 1 server.

Get started free