CVE-2026-89635: Software Security Vulnerability Vulnerability

CRITICAL
Advisory Identifier: GHSA-rg7m-2q29-w52v
Share
CVSS 9.8
Published
Advisory Summary

CVE-2026-89635 is a CRITICAL (CVSS 9.8) security vulnerability vulnerability (General Security Weakness) affecting Software libraries in the Maven ecosystem. Remediation is available in the latest vendor maintenance releases.

CVE-2026-89635 at a Glance

CVE Identifier CVE-2026-89635
GHSA Identifier GHSA-rg7m-2q29-w52v
Severity CRITICAL
CVSS v3.1 Base Score 9.8
CWE Classification General Security Weakness
Affected Product Software
Package Ecosystem Maven
Published Date
Last Updated

Security Impact

CVSS: 9.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-89635

To remediate this vulnerability, upgrade all affected Software dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release: 

mvn dependency:tree

How to Check if You Are Affected

To determine whether your Java application is affected by CVE-2026-89635, inspect your build dependencies using the Maven Dependency Plugin:

mvn dependency:tree

Analyze the terminal output to locate any version of Software in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.

Note: The mvn dependency:tree command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under General Security Weakness. In Software, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

In the Linux kernel, the following vulnerability has been resolved: ksmbd: only rebind the reopened file's own oplock on durable reconnect ksmbd_reopen_durable_fd() walks the inode's m_op_list and rebinds every detached oplock to the reconnecting session: list_for_each_entry_rcu(op, &ci->m_op_list, op_entry, lockdep_is_held(&ci->m_lock)) { if (op->conn) continue; op->conn = ksmbd_conn_get(fp->conn); op->sess = work->sess; } The only key is op->conn == NULL, which every detached durable handle on that inode matches, not just the one owned by fp. When two sessions hold durable handles on the same file and both disconnect, reconnecting one of them adopts the other session's oplock: op->sess is overwritten with the reconnecting session without taking a reference on it, while op->conn pins the connection. The sibling teardown path, session_fd_check(), keys on the identity of the connection being torn down (op->conn == conn) rather than on shared state, and so does not have this problem. Once the adopting session is destroyed, ksmbd_session_destroy() frees it while the foreign oplock still points at it. The reader in ksmbd_close_fd_app_instance_id() validates only opinfo->conn, which is still live thanks to the reference taken above, and then dereferences the stale session: if (!opinfo->conn) { up_read(&fp->f_ci->m_lock); goto out; } ft = &opinfo->sess->file_table; write_lock(&ft->lock); BUG: KASAN: slab-use-after-free in _raw_write_lock+0x74/0xd0 Write of size 4 at addr ffff88810a970528 by task kworker/0:0/9 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: _raw_write_lock+0x74/0xd0 ksmbd_close_fd_app_instance_id+0x183/0x410 smb2_open+0x1346/0x4430 handle_ksmbd_work+0x2bb/0x7b0 Reached from an authenticated session against a share with the default durable-handle and oplock configuration: two sessions open the same file with a durable-v2 handle and an RH lease under distinct AppInstanceIds, both log off, one reconnects with DH2C, and a later durable-v2 create carrying the other AppInstanceId walks into the freed session. Constrain the loop to the oplock owned by the file being reopened.

References

NVD — CVE-2026-89635 NVD
https://nvd.nist.gov/vuln/detail/CVE-2026-89635
git.kernel.org/stable/c/3f220a0a62... WEB
https://git.kernel.org/stable/c/3f220a0a62e6b9b391c9d1f0e6580b05173cc7f7
git.kernel.org/stable/c/74e3ef4630... WEB
https://git.kernel.org/stable/c/74e3ef4630f004c0de40c0540648a5a4033c6c9d

Frequently Asked Questions

What is CVE-2026-89635?
CVE-2026-89635 is a security vulnerability in Software classified as a security vulnerability vulnerability under General Security Weakness.
Which Software versions are affected?
Affected versions include releases prior to current release patches.
What version fixes CVE-2026-89635?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
What is the CVSS score of CVE-2026-89635?
CVE-2026-89635 has a CVSS v3.1 base score of 9.8 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with CVE-2026-89635?
CVE-2026-89635 is classified under General Security Weakness.
How can I check Maven dependencies for CVE-2026-89635?
Run the dependency tree command: 'mvn dependency:tree'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
View Raw JSON 
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-rg7m-2q29-w52v",
  "modified" : "2026-09-13T09:32:25Z",
  "published" : "2026-09-11T21:31:34Z",
  "aliases" : [ "CVE-2026-89635" ],
  "details" : "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: only rebind the reopened file's own oplock on durable reconnect\n\nksmbd_reopen_durable_fd() walks the inode's m_op_list and rebinds every\ndetached oplock to the reconnecting session:\n\n\tlist_for_each_entry_rcu(op, &ci->m_op_list, op_entry,\n\t\t\t\tlockdep_is_held(&ci->m_lock)) {\n\t\tif (op->conn)\n\t\t\tcontinue;\n\t\top->conn = ksmbd_conn_get(fp->conn);\n\t\top->sess = work->sess;\n\t}\n\nThe only key is op->conn == NULL, which every detached durable handle on\nthat inode matches, not just the one owned by fp.  When two sessions hold\ndurable handles on the same file and both disconnect, reconnecting one of\nthem adopts the other session's oplock: op->sess is overwritten with the\nreconnecting session without taking a reference on it, while op->conn\npins the connection.\n\nThe sibling teardown path, session_fd_check(), keys on the identity of\nthe connection being torn down (op->conn == conn) rather than on shared\nstate, and so does not have this problem.\n\nOnce the adopting session is destroyed, ksmbd_session_destroy() frees it\nwhile the foreign oplock still points at it.  The reader in\nksmbd_close_fd_app_instance_id() validates only opinfo->conn, which is\nstill live thanks to the reference taken above, and then dereferences the\nstale session:\n\n\tif (!opinfo->conn) {\n\t\tup_read(&fp->f_ci->m_lock);\n\t\tgoto out;\n\t}\n\n\tft = &opinfo->sess->file_table;\n\twrite_lock(&ft->lock);\n\n  BUG: KASAN: slab-use-after-free in _raw_write_lock+0x74/0xd0\n  Write of size 4 at addr ffff88810a970528 by task kworker/0:0/9\n  Workqueue: ksmbd-io handle_ksmbd_work\n  Call Trace:\n   _raw_write_lock+0x74/0xd0\n   ksmbd_close_fd_app_instance_id+0x183/0x410\n   smb2_open+0x1346/0x4430\n   handle_ksmbd_work+0x2bb/0x7b0\n\nReached from an authenticated session against a share with the default\ndurable-handle and oplock configuration: two sessions open the same file\nwith a durable-v2 handle and an RH lease under distinct AppInstanceIds,\nboth log off, one reconnects with DH2C, and a later durable-v2 create\ncarrying the other AppInstanceId walks into the freed session.\n\nConstrain the loop to the oplock owned by the file being reopened.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
  } ],
  "affected" : [ ],
  "references" : [ {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-89635"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/3f220a0a62e6b9b391c9d1f0e6580b05173cc7f7"
  }, {
    "type" : "WEB",
    "url" : "https://git.kernel.org/stable/c/74e3ef4630f004c0de40c0540648a5a4033c6c9d"
  } ],
  "database_specific" : {
    "cwe_ids" : [ ],
    "severity" : "CRITICAL",
    "github_reviewed" : false,
    "github_reviewed_at" : null,
    "nvd_published_at" : "2026-09-11T20:19:49Z"
  }
}