UBUNTU-CVE-2026-89493: High severity ubuntu/linux vulnerability
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
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 - Compensating control
In ocfs2_validate_refcount_block(), add checks equivalent to ocfs2_validate_extent_block(): when !(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL), reject the refcount block via ocfs2_error() if rl_count does not equal ocfs2_refcount_recs_per_rb(sb), or if rl_used > rl_count, before any refcount record array is traversed.
Event History
Frequently Asked Questions
Which Ubuntu kernel package families are identified as affected?
The listed packages are ubuntu/linux, ubuntu/linux-fips, ubuntu/linux-aws, ubuntu/linux-azure, ubuntu/linux-aws-fips, ubuntu/linux-azure-fips, ubuntu/linux-gcp, and ubuntu/linux-gcp-fips.
What condition is needed to trigger the vulnerable code path?
A crafted or corrupted OCFS2 on-disk refcount block must contain invalid refcount-list values, such as rl_used set to 0xffff. A subsequent refcount, reflink, or copy-on-write operation must walk that refcount record array.
What is the potential impact of malformed refcount metadata?
The kernel can walk beyond the metadata block's refcount-record array and pass an out-of-range index to an insertion routine. The described insertion shift can then perform an out-of-bounds memmove; the reported vector rates confidentiality, integrity, and availability impact as high.