CVE-2026-98870 json
ksmbd: remove stale channels from all sessions on teardown
published 19d ago modified 18d ago also EUVD-2026-108716
- cvss
- 8.8
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.5%
- EPSS 0.5% chance of exploitation in 30 days, percentile 46%
- public exploits
- 0
- none known
Summary
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: remove stale channels from all sessions on teardown
ksmbd_sessions_deregister() removes a connection's channels from other sessions' channel lists only while conn->binding is still set:
if (conn->binding) { hash_for_each_safe(sessions_table, ...) ksmbd_chann_del(conn, sess); }
conn->binding is a transient flag: it is cleared once a binding SESSION_SETUP completes, and also by a subsequent non-binding SESSION_SETUP on the same connection (a reauthentication on a bound channel, or a new SessionId==0 setup). A connection that has bound a channel into another session's ksmbd_chann_list and then clears conn->binding leaves that channel behind when it disconnects: the channel, whose chann->conn points at the now freed struct ksmbd_conn, stays on the owner session's list.
When the owning connection later tears down, the second loop dereferences the stale channel:
xa_for_each(&sess->ksmbd_chann_list, chann_id, chann) if (chann->conn != conn) ksmbd_conn_set_exiting(chann->conn); /* freed */
which is a use-after-free write into the freed ksmbd_conn (the same stale channel is also walked by show_proc_session() through /proc). The session is leaked as well, because its channel list never empties.
Remove the conn->binding gate so a connection always removes its channels from every session on teardown.
Patch / fix
- Linux Linux 5.16
- git.kernel.org/stable/c/f8200bb4994e65a2e5c5b314789eeae39078619d commit
- git.kernel.org/stable/c/9cd6d714d3ca0cff296542dc989696884e41970f commit
- git.kernel.org/stable/c/b145f9b56c87f9c23ad5464ab0844dbc1de12b36 commit
- git.kernel.org/stable/c/a15cae16f4432a5ad919ee633e31b07178492955 commit
- git.kernel.org/stable/c/b10665730fbf6b5e45fe422badcbbc3f0df96ef5 commit
Is CVE-2026-98870 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerVendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-98870 updated cvss 6.5
kernel: ksmbd: remove stale channels from all sessions on teardown
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8, openshift/ose-rhel-coreos-9not affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.54% chance of exploitation in the next 30 days, higher than 46% of all scored CVEs (FIRST EPSS, 2026-11-11).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 8.8 | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/f8200bb4994e65a2e5c5b314789eeae39078619d
- git.kernel.org /stable/c/9cd6d714d3ca0cff296542dc989696884e41970f
- git.kernel.org /stable/c/b145f9b56c87f9c23ad5464ab0844dbc1de12b36
- git.kernel.org /stable/c/a15cae16f4432a5ad919ee633e31b07178492955
- git.kernel.org /stable/c/b10665730fbf6b5e45fe422badcbbc3f0df96ef5
Sources
- CVE List CVE-2026-98870
- NVD CVE-2026-98870
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.