Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%
Buy Us a Coffee

CVE-2026-89493— ocfs2: validate rl_used against rl_count in refcount block validator

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

Linux kernel是美国Linux基金会开源的一个操作系统内核。 Linux kernel 2.6.32版本存在安全漏洞，该漏洞源于ocfs2的refcount块验证器未校验rl_used与rl_count，可能导致越界读取和越界内存移动，造成内存损坏，本地攻击者可通过挂载特制或损坏的ocfs2镜像触发。

CVSS 8.8 · High EPSS 0.65% · P50

Possible ATT&CK Techniques 1 AI

T1059 · Command and Scripting Interpreter

Affected Version Matrix 18

VendorProduct Version RangeStatus
Linux Linux f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< f882e9e32d017a6569b2996c63ba3864717788e6 affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< 5593b63028cb43a6cda75a65ce1db95f00ea6857 affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< c8b02f4ee91e757b3fff556c7168b24b7ae55132 affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< 97584e93fc49a2d59252ac60467e9279f11b1b5b affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< af56e90cb546cb0c47bef059335365283f61d6a4 affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< 0761d2c9494424469a0d30a9da3496ca010b0b2d affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< 04ead708e13ddcb9c39319cbe02a18cef99cb823 affected
f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4< 4ca62df6bc0708947b48da3f6a712ecb8e73929c affected
… +10 more rows
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-89493

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
ocfs2: validate rl_used against rl_count in refcount block validator
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate rl_used against rl_count in refcount block validator ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array with: for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) { rec = &rb->rf_records.rl_recs[i]; ... rl_recs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the 16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly off disk by ocfs2_validate_refcount_block() and are never checked against that capacity, nor against each other, before any refcount/reflink/CoW operation walks the array. A crafted (or corrupted) refcount block with rl_used == 0xffff makes the loop above walk far past the end of the block, dereferencing rl_recs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2_insert_refcount_rec(), whose insert-shift does: if (index < le16_to_cpu(rf_list->rl_used)) memmove(&rf_list->rl_recs[index + 1], &rf_list->rl_recs[index], (le16_to_cpu(rf_list->rl_used) - index) * sizeof(struct ocfs2_refcount_rec)); i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an offset already past the block. This is reachable from an ordinary reflink (FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent whose cpos sorts past every real record in the leaf forces the lookup to run off the end instead of returning early on a match. The attacker model is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem. ocfs2_validate_refcount_block() already validates the block's ECC, signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used against the block's actual on-disk capacity. This is the same class of gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes for the sibling extent-list header, which checks both the record capacity and the "used" bound before any code walks h_list.l_recs[]: if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) { rc = ocfs2_error(...); goto bail; } if (le16_to_cpu(eb->h_list.l_next_free_rec) > le16_to_cpu(eb->h_list.l_count)) { rc = ocfs2_error(...); goto bail; } Add the equivalent pair of checks to ocfs2_validate_refcount_block(): reject a refcount block whose rl_count does not match the fixed per-block capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used > rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set, because in that case the same union bytes hold an ocfs2_extent_list (rf_list), not the refcount record list (rf_records) -- that layout is already validated separately by ocfs2_validate_extent_block() when the referenced extent block is read. This mirrors the existing "!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)" guard used elsewhere in this file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or rf_list is the live member of the union. With this in place, a forged rl_used/rl_count is caught at block validation time (ocfs2_error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove() in ocfs2_insert_refcount_rec(). Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in __ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch, and triggers no report once ocfs2_validate_refcount_block() rejects the forged rl_used/rl_count.
Source: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会开源的一个操作系统内核。 Linux kernel 2.6.32版本存在安全漏洞，该漏洞源于ocfs2的refcount块验证器未校验rl_used与rl_count，可能导致越界读取和越界内存移动，造成内存损坏，本地攻击者可通过挂载特制或损坏的ocfs2镜像触发。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux f2c870e3b12e38da6d9b5b17c4c8ae56a0ed68e4 ~ f882e9e32d017a6569b2996c63ba3864717788e6 -
Linux Linux 2.6.32 -

II. Public POCs for CVE-2026-89493

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-89493

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-89493 (8)

Same Patch Batch · Linux · 2026-09-11 · 430 CVEs total

CVE-2026-89703 9.8 CRITICAL nfsd: set SC_STATUS_FREED in nfsd4_drop_revoked_stid for delegations
CVE-2026-89689 9.8 CRITICAL nfsd: don't free session slots that are still in use
CVE-2026-89558 9.8 CRITICAL md/raid10: fix still_degraded being inverted in raid10_sync_request()
CVE-2026-89555 9.8 CRITICAL mpls: reload header after pskb_may_pull()
CVE-2026-89550 9.8 CRITICAL SUNRPC: svcauth_gss: enforce krb5 token minimum length
CVE-2026-89551 9.8 CRITICAL SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow
CVE-2026-89546 9.8 CRITICAL SUNRPC: close backchannel before destroying callback service
CVE-2026-89542 9.8 CRITICAL SUNRPC: harden gss_krb5_unwrap_v2 against short tokens
CVE-2026-89541 9.8 CRITICAL SUNRPC: harden gss_unwrap_resp_priv length checks
CVE-2026-89538 9.8 CRITICAL SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field
CVE-2026-89536 9.8 CRITICAL SUNRPC: wait for in-flight client TLS handshake callback
CVE-2026-89533 9.8 CRITICAL svcrdma: Fix offset arithmetic in read_chunk_range
CVE-2026-89530 9.8 CRITICAL svcrdma: Reject inline replies that overflow the pull-up buffer
CVE-2026-89526 9.8 CRITICAL svcrdma: Validate Read chunk positions before reconstruction
CVE-2026-81002 9.8 CRITICAL xdp: fix zero-copy frame layout
CVE-2026-89482 9.8 CRITICAL nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone
CVE-2026-89478 9.8 CRITICAL sctp: drop a chunk if its transport was removed
CVE-2026-89479 9.8 CRITICAL sctp: stop processing a packet once its association is deleted
CVE-2026-89485 9.8 CRITICAL lockd: pin next file across nlm_inspect_file lock-drop
CVE-2026-80986 9.8 CRITICAL net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages

Showing top 20 of 430 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

Same product: Linux
Same vendor: Linux

V. Comments for CVE-2026-89493

No comments yet

Leave a comment