CVE-2026-89496

What it actually does

This is a Linux kernel memory leak in OCFS2’s copy-on-write completion path. When copy_file_range (and related splice/sendfile write paths) operates on refcounted extents in the same OCFS2 filesystem, extent-tree rotation, split/merge, and cluster replacement cache block-deallocation records via ocfs2_cache_block_dealloc without always flushing the deferred dealloc context. The leaked objects are small slab allocations (typically 32-byte dealloc cache/list records). Repeated CoW operations accumulate unreclaimed kernel memory, which can exhaust kmalloc/slab capacity and degrade or panic the node. Impact is availability (DoS family); the flaw is not described as a privilege-escalation, remote code-execution, or information-disclosure primitive.

Why it matters to the business

Hosts that mount OCFS2—commonly clustered databases, shared-disk HA, and Linux clustering stacks—can experience gradual memory growth, unexplained performance loss, or unplanned node restarts if CoW/copy workloads run for a long time. Business impact is operational downtime of clustered applications rather than data theft. EPSS is about 0.0018 and has been flat over 30 days, the CVE is not in CISA KEV, ransomware use is not reported, and exploit maturity is none, so urgency is lower than for remotely exploitable kernel bugs. Prioritize long-lived OCFS2 cluster nodes that frequently reflink or copy files in place. No per-product prevalence or fixed-package list was supplied; treat any production OCFS2 kernel as in-scope until the dealloc-on-CoW fix is confirmed present.

How an attack unfolds

An attacker who can write to an OCFS2 volume (local user, container, or compromised service sharing the mount) targets files with shared/refcounted clusters, such as after reflink. They induce copy-on-write through copy_file_range, sendfile, or splice-backed writes so the kernel runs ocfs2_refcount_cow / ocfs2_replace_cow, caches dealloc records, and (on unpatched kernels) never runs those deallocs at CoW completion. Looping the operation grows unreclaimed slab objects until the node is slow, OOM-killed, or panics. Exploitation requires local filesystem access and an OCFS2 mount; no unauthenticated network path is described. No named APT groups or campaigns are associated with this issue.

How to fix it

Apply the upstream Linux kernel change that always runs OCFS2 deallocs on copy-on-write completion (ocfs2: always run deallocs on copy-on-write completion). Upgrade to a distribution kernel whose changelog or CVE mapping includes this fix. Exact vendor package versions were not provided, so confirm via your distro security tracker for CVE-2026-89496 or the ocfs2 CoW dealloc commit. Until patched, limit untrusted writers on OCFS2 mounts, avoid high-rate copy_file_range/sendfile against reflinked files, and isolate cluster nodes. There is no complete userspace workaround that reclaims the leaked kernel objects without a patched kernel.

How to confirm the fix worked

Confirm the running kernel includes the OCFS2 CoW dealloc-on-completion fix via vendor advisory, package changelog, or kernel git history. Inventory hosts with ocfs2 in /proc/filesystems or mounted ocfs2 volumes. On a test system, exercise copy_file_range/sendfile on reflinked OCFS2 files under kmemleak or slab accounting; unreferenced objects from ocfs2_cache_block_dealloc / ocfs2_find_per_slot_free_list must not accumulate, and kmalloc-32 (or equivalent small-slab) usage should stay stable. After production rollout, verify module/kernel version and the absence of new kmemleak reports on the CoW path.

Typical attack path

1. Obtain local execution or a write-capable process on a host with OCFS2 mounted.
2. Locate or create refcounted/shared-cluster files (for example via reflink or existing CoW sharing).
3. Repeatedly invoke copy_file_range, sendfile, or splice writes that force OCFS2 refcount CoW (ocfs2_refcount_cow / ocfs2_replace_cow).
4. Allow leaked dealloc-cache slab objects to accumulate in kernel memory.
5. Continue until memory pressure causes service degradation, OOM, or node crash (denial of service).

How to detect it

This is a local kernel memory leak, not a network implant, so perimeter IDS will not flag it. Hunt for leak evidence and for the triggering workload. If kmemleak is enabled, search kernel logs for unreferenced objects whose backtraces include ocfs2_cache_block_dealloc, ocfs2_unlink_path, ocfs2_replace_cow, ocfs2_refcount_cow, ocfs2_file_write_iter, or ocfs2_find_per_slot_free_list. Review dmesg/journalctl for kmemleak dumps and OOM events on processes using splice, sendfile, or copy_file_range against OCFS2. Watch /proc/slabinfo for sustained growth of small kmalloc caches coincident with OCFS2 CoW activity. Audit high-rate copy_file_range or sendfile syscalls on ocfs2 mounts. No in-the-wild campaign artifacts or named-actor TTPs are documented.

• ocfs2_cache_block_dealloc
• ocfs2_find_per_slot_free_list
• ocfs2_cache_extent_block_free
• ocfs2_replace_cow
• ocfs2_refcount_cow
• ocfs2_make_clusters_writable
• ocfs2_clear_ext_refcount
• ocfs2_file_write_iter
• kmemleak_alloc_recursive
• unreferenced object

What your security team should do

• Inventory Linux hosts that mount OCFS2 and rank clustered/database nodes first for kernel updates.
• Deploy vendor kernels that contain the OCFS2 always-run-deallocs-on-CoW fix; confirm CVE-2026-89496 or the matching commit in the changelog.
• Until patched, restrict write, reflink, and copy_file_range/sendfile use on OCFS2 to trusted services.
• Monitor kernel memory (slabinfo, kmemleak, OOM) on OCFS2 nodes for unexplained small-kmalloc growth tied to CoW/copy workloads.
• Given low EPSS (~0.0018, flat), no KEV listing, no ransomware use, and exploit maturity none, use normal kernel patch cadence unless OCFS2 underpins business-critical clustered storage—in that case treat availability risk as higher operational priority.