CVE-2026-89493: ocfs2: validate rl_used against rl_count in refcount block validator
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate rlused against rlcount in refcount block validator
ocfs2findrefcountrecinrl() walks the on-disk refcount record array with:
for (; i < le16tocpu(rb->rfrecords.rlused); i++) { rec = &rb->rfrecords.rlrecs[i]; ...
rlrecs[] lives in a single metadata block (4096 bytes on the common configuration), so its real capacity is fixed by ocfs2refcountrecsperrb(sb) (247 records for a 4K block with the 16-byte ocfs2refcountrec). rlused and rlcount are both read directly off disk by ocfs2validaterefcountblock() 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 rlused == 0xffff makes the loop above walk far past the end of the block, dereferencing rlrecs[i] for i up to 65534. The resulting index is then handed to the sibling ocfs2insertrefcountrec(), whose insert-shift does:
if (index < le16tocpu(rflist->rlused)) memmove(&rflist->rlrecs[index + 1], &rflist->rlrecs[index], (le16tocpu(rflist->rlused) - index) sizeof(struct ocfs2refcountrec));
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: CAPSYSADMIN mounting a crafted or corrupted ocfs2 image, or a raw write to the block device backing an already-mounted ocfs2 filesystem.
ocfs2validaterefcountblock() already validates the block's ECC, signature, rfblkno and rffsgeneration, but never rlcount/rlused against the block's actual on-disk capacity. This is the same class of gap that ocfs2validateextentblock() (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 hlist.lrecs[]:
if (le16tocpu(eb->hlist.lcount) != ocfs2extentrecspereb(sb)) { rc = ocfs2error(...); goto bail; }
if (le16tocpu(eb->hlist.lnextfreerec) > le16tocpu(eb->hlist.lcount)) { rc = ocfs2error(...); goto bail; }
Add the equivalent pair of checks to ocfs2validaterefcountblock(): reject a refcount block whose rlcount does not match the fixed per-block capacity returned by ocfs2refcountrecsperrb(), and reject rlused > rlcount. Both checks are skipped when OCFS2REFCOUNTTREEFL is set, because in that case the same union bytes hold an ocfs2extentlist (rflist), not the refcount record list (rfrecords) -- that layout is already validated separately by ocfs2validateextentblock() when the referenced extent block is read. This mirrors the existing "!(rb->rfflags & OCFS2REFCOUNTTREEFL)" guard used elsewhere in this file (e.g. ocfs2getrefcountrec()) to decide whether rfrecords or rflist is the live member of the union.
With this in place, a forged rlused/rlcount is caught at block validation time (ocfs2error()), consistent with every other corruption check in this function, instead of driving an out-of-bounds read in ocfs2findrefcountrecinrl() and a subsequent out-of-bounds memmove() in ocfs2insertrefcountrec().
Verified against a crafted image on a v6.19 KASAN (KASANGENERIC) build: replaying the same reflink (FICLONE) reliably hit a KASAN report in ocfs2increaserefcount()/ocfs2insertrefcountrec() before this patch, and triggers no report once ocfs2validaterefcountblock() rejects the forged rlused/rlcount.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1124.133 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
Which environments are exposed to this issue?
Linux systems using OCFS2 are exposed when they perform refcount, reflink, or copy-on-write operations that walk an on-disk refcount record array. The issue concerns malformed or corrupted OCFS2 refcount blocks.
What does an attacker need to control to trigger the vulnerable path?
The attacker needs a crafted on-disk refcount block, or an existing refcount block must be corrupted. In particular, a malicious rl_used value can cause the kernel to iterate beyond the metadata block's refcount-record array.
What on-disk values indicate a dangerous refcount block?
A refcount block is dangerous when rl_used or rl_count exceeds the record capacity of its metadata block, or when the two values are inconsistent. On a common 4K-block configuration, the described record-array capacity is 247 records; rl_used set to 0xffff can drive traversal far beyond that boundary.