CVE-2025-22079

What it actually does

The flaw permits out-of-bounds memory access during OCFS2 extent tree traversal when an on-disk l_tree_depth value exceeds OCFS2_MAX_PATH_DEPTH; the 16-bit field is read from potentially corrupted media without validation before indexing internal kernel structures.

Why it matters to the business

Systems using the OCFS2 clustered filesystem risk kernel instability, crashes, or memory corruption when mounting attacker-controlled or corrupted volumes, leading to service outages in storage clusters or high-availability setups; the low EPSS and absence from KEV indicate limited observed exploitation but still require prompt patching given the kernel's foundational role.

How an attack unfolds

An attacker prepares a malicious OCFS2 filesystem image containing an invalid l_tree_depth larger than the defined maximum, then causes the target kernel to mount the image (via local device, network share, or container volume); during metadata parsing the unchecked depth triggers an out-of-bounds read or write in kernel memory.

How to fix it

Apply the upstream fix (commit ef34840bda333fe99bafbd2d73b70ceaaf9eba66) or later; for affected Red Hat packages update libreswan to 0:4.6-3.el9_0.3 (or equivalent) and ensure the running kernel contains the ocfs2 depth validation; rebuild and reboot with the patched kernel, then verify the mount path rejects invalid depth values.

How to confirm the fix worked

Confirm the patched kernel source contains the l_tree_depth bounds check before OCFS2_MAX_PATH_DEPTH usage; test by attempting to mount a crafted image with excessive depth and verify the operation is rejected without kernel oops or panic.

Typical attack path

1. Craft OCFS2 disk image with l_tree_depth exceeding OCFS2_MAX_PATH_DEPTH
2. Deliver the image to the target (USB, network filesystem, container layer)
3. Trigger mount operation on the corrupted volume
4. Kernel extent-tree walker performs unbounded array access
5. Resulting memory corruption or panic occurs

How to detect it

Inspect kernel logs (dmesg, /var/log/kern.log, journalctl) for OCFS2 extent-tree or l_tree_depth related oops/panic messages; correlate mount events of OCFS2 volumes with subsequent crashes; no widespread threat-actor campaigns are documented.

What your security team should do

• Prioritize kernel updates containing the ocfs2 validation fix across all OCFS2-using systems
• Restrict mounting of OCFS2 volumes to trusted sources only
• Enable filesystem integrity checks and monitor kernel logs for ocfs2-related faults
• Review downstream package dependencies for the fixed commit and schedule reboots