high CVSS 8.8

CVE-2026-98115·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: ksmbd: safely drain sessions during logoff SMB3 multichannel allows requests for one session to run on multiple connections. Wait for all channels bound to a session before freeing shared session objects. A deferred byte-range lock remains counted as a running request and only wakes when its file closes. Wake blocked locks during the drain without unpublishing or modifying their file objects. Synchronous CANCEL requests must invoke their cancellation callback to wake pending operations, while CHANGE_NOTIFY completion remains specific to the asynchronous path. Serialize session teardown with channel registration and previous-session cleanup, and use atomic work-state transitions so LOGOFF, CANCEL, and connection teardown invoke cancellation callbacks only once.

Severity: high
Software: Kernel
Fixed in: 7.2.7
Published: 2026-09-25

Affected versions

From: 6.11.1

Until: 7.2.7

Fixed in: 7.2.7

How to fix this CVE

Update your Linux kernel to version 7.2.7 or later to fix a critical session management vulnerability in the ksmbd SMB3 server implementation. The vulnerability affects systems using kernel versions 6.11.1 through 7.2.6 and could allow authenticated users to trigger race conditions during session teardown. Apply the update immediately, followed by a system reboot to activate the patched kernel.

sudo dnf update kernel && sudo reboot

Defensia detects this vulnerability

How to check if you are affected

Step 1: Check your current kernel version by running 'uname -r' and verify it falls within 6.11.1 to 7.2.6
Step 2: Confirm ksmbd is enabled by checking 'cat /proc/fs/ksmbd/debug' or 'lsmod | grep ksmbd' for active SMB3 server functionality
Step 3: Review system logs for session teardown anomalies with 'grep -i 'ksmbd\|smb.*logoff\|session.*drain' /var/log/kern.log /var/log/messages' to identify exploitation attempts
Step 4: After patching, verify the new kernel is running with 'uname -r' and confirm it shows version 7.2.7 or later

FAQ

What is CVE-2026-98115?

This is a kernel vulnerability in ksmbd (Linux SMB3 server) where improper session teardown during logoff could lead to race conditions in multichannel sessions. An authenticated attacker could potentially cause denial of service or trigger memory corruption when sessions are terminated.

Is CVE-2026-98115 being actively exploited?

No, this vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities catalog and no public exploit code is available, though it should still be prioritized as a high-severity kernel issue.

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

Linux kernel versions 6.11.1 through 7.2.6 are vulnerable. The vulnerability is resolved in kernel version 7.2.7 and later.

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

Run 'uname -r' to display your kernel version and cross-reference it against the affected range 6.11.1–7.2.6. If your kernel version falls within that range and ksmbd is active ('lsmod | grep ksmbd'), your system is vulnerable.

Does Defensia detect CVE-2026-98115?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If the Linux kernel is installed on a monitored server, CVE-2026-98115 will appear in your dashboard with remediation steps.

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-98115. Free for 1 server.

Get started free