CVE-2026-89493: Software Security Vulnerability Vulnerability
HIGHCVE-2026-89493 is a HIGH (CVSS 8.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-89493 at a Glance
Security Impact
CVSS: 8.8
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
How to Fix CVE-2026-89493
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.
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-89493, 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
References
Frequently Asked Questions
What is CVE-2026-89493?
Which Software versions are affected?
What version fixes CVE-2026-89493?
What is the CVSS score of CVE-2026-89493?
What CWE is associated with CVE-2026-89493?
How can I check Maven dependencies for CVE-2026-89493?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-8g63-4gj4-crp5",
"modified" : "2026-09-14T15:32:27Z",
"published" : "2026-09-11T21:31:29Z",
"aliases" : [ "CVE-2026-89493" ],
"details" : "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate rl_used against rl_count in refcount block validator\n\nocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array\nwith:\n\n\tfor (; i < le16_to_cpu(rb->rf_records.rl_used); i++) {\n\t\trec = &rb->rf_records.rl_recs[i];\n\t\t...\n\nrl_recs[] lives in a single metadata block (4096 bytes on the common\nconfiguration), so its real capacity is fixed by\nocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the\n16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly\noff disk by ocfs2_validate_refcount_block() and are never checked against\nthat capacity, nor against each other, before any refcount/reflink/CoW\noperation walks the array.\n\nA crafted (or corrupted) refcount block with rl_used == 0xffff makes the\nloop above walk far past the end of the block, dereferencing rl_recs[i]\nfor i up to 65534. The resulting index is then handed to the sibling\nocfs2_insert_refcount_rec(), whose insert-shift does:\n\n\tif (index < le16_to_cpu(rf_list->rl_used))\n\t\tmemmove(&rf_list->rl_recs[index + 1],\n\t\t\t&rf_list->rl_recs[index],\n\t\t\t(le16_to_cpu(rf_list->rl_used) - index) *\n\t\t\t sizeof(struct ocfs2_refcount_rec));\n\ni.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an\noffset already past the block. This is reachable from an ordinary reflink\n(FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent\nwhose cpos sorts past every real record in the leaf forces the lookup to\nrun off the end instead of returning early on a match. The attacker model\nis local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a\nraw write to the block device backing an already-mounted ocfs2 filesystem.\n\nocfs2_validate_refcount_block() already validates the block's ECC,\nsignature, rf_blkno and rf_fs_generation, but never rl_count/rl_used\nagainst the block's actual on-disk capacity. This is the same class of\ngap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes\nfor the sibling extent-list header, which checks both the record capacity\nand the \"used\" bound before any code walks h_list.l_recs[]:\n\n\tif (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {\n\t\trc = ocfs2_error(...);\n\t\tgoto bail;\n\t}\n\n\tif (le16_to_cpu(eb->h_list.l_next_free_rec) >\n\t le16_to_cpu(eb->h_list.l_count)) {\n\t\trc = ocfs2_error(...);\n\t\tgoto bail;\n\t}\n\nAdd the equivalent pair of checks to ocfs2_validate_refcount_block():\nreject a refcount block whose rl_count does not match the fixed per-block\ncapacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used >\nrl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set,\nbecause in that case the same union bytes hold an ocfs2_extent_list\n(rf_list), not the refcount record list (rf_records) -- that layout is\nalready validated separately by ocfs2_validate_extent_block() when the\nreferenced extent block is read. This mirrors the existing\n\"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)\" guard used elsewhere in this\nfile (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or\nrf_list is the live member of the union.\n\nWith this in place, a forged rl_used/rl_count is caught at block\nvalidation time (ocfs2_error()), consistent with every other corruption\ncheck in this function, instead of driving an out-of-bounds read in\nocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove()\nin ocfs2_insert_refcount_rec().\n\nVerified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build:\nreplaying the same reflink (FICLONE) reliably hit a KASAN report in\n__ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch,\nand triggers no report once ocfs2_validate_refcount_block() rejects the\nforged rl_used/rl_count.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
} ],
"affected" : [ ],
"references" : [ {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-89493"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/04ead708e13ddcb9c39319cbe02a18cef99cb823"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/0761d2c9494424469a0d30a9da3496ca010b0b2d"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/4ca62df6bc0708947b48da3f6a712ecb8e73929c"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/5593b63028cb43a6cda75a65ce1db95f00ea6857"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/97584e93fc49a2d59252ac60467e9279f11b1b5b"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/af56e90cb546cb0c47bef059335365283f61d6a4"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/c8b02f4ee91e757b3fff556c7168b24b7ae55132"
}, {
"type" : "WEB",
"url" : "https://git.kernel.org/stable/c/f882e9e32d017a6569b2996c63ba3864717788e6"
} ],
"database_specific" : {
"cwe_ids" : [ ],
"severity" : "HIGH",
"github_reviewed" : false,
"github_reviewed_at" : null,
"nvd_published_at" : "2026-09-11T20:19:31Z"
}
}