Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix out-of-bounds write in ocfs2_remove_refcount_extent [BUG] Unlinking a refcounted file whose refcount tree has leaf blocks triggers a fortify panic due to an out-of-bounds write. [CAUSE] When the last leaf block is removed from a refcount tree, ocfs2_remove_refcount_extent() converts the root back to leaf mode with a bulk memset on &rb->rf_records. rf_records sits in an anonymous union with rf_list. rf_list.l_tree_depth aliases rf_records.rl_count, and is 0 for a single-level tree. With rl_count equal to 0, the memset writes past the 16-byte declared size of rf_records, which the fortify checker catches. [FIX] Replace the bulk memset on &rb->rf_records with a correctly-bounded memset on rl_recs[] alone, after setting rl_count to the correct value.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-28T08:16:48.720Z",
  "pubdate": "2026-08-28T08:16:48.720Z",
  "executiveSummary": "A memory corruption vulnerability exists in the OCFS2 (Oracle Cluster File System version 2) implementation within the Linux kernel, specifically during the handling of refcount tree transitions.\nThe vulnerability is classified as an out-of-bounds (OOB) write, triggered when a refcounted file is unlinked and the associated refcount tree is transitioned back to leaf mode.\nThe flaw stems from an improper memset operation that fails to respect the boundaries of the refcount record structure, leading to a fortify panic.\nThe risk implication is high, as it can lead to kernel-level memory corruption, potential system instability, or service denial via a kernel panic.\nAn attacker capable of triggering the unlink of a specific refcounted file on an OCFS2 filesystem can induce this fault, requiring local access to the filesystem.\nThis vulnerability highlights risks associated with improper structure aliasing and buffer initialization within the kernel's memory management subsystems.",
  "technicalDetails": "The root cause of the vulnerability lies in ocfs2_remove_refcount_extent() within the OCFS2 kernel module. When the final leaf block of a refcount tree is removed, the system attempts to revert the refcount tree root to a leaf state.\nThe data structure involved, ocfs2_refcount_block, utilizes an anonymous union where rf_records and rf_list reside at the same memory offset. Specifically, the rf_list.l_tree_depth field aliases the rl_count field within rf_records.\nDuring the transition, the code performs a bulk memset on &rb->rf_records. Because the tree is treated as a single-level tree, the l_tree_depth value is 0. However, the initialization logic erroneously uses this state to calculate the memset length, leading the operation to write beyond the 16-byte boundary defined for the rf_records array.\nThe Linux kernel's FORTIFY_SOURCE mechanism detects this boundary violation, resulting in a controlled panic to prevent further memory corruption.\nThe exploitation flow begins with the manipulation of a refcounted file on an OCFS2 filesystem. An attacker must perform an operation that triggers the removal of the last leaf block from the refcount tree, such as unlinking a file that shares refcounted blocks. When the kernel reaches the logic to collapse the tree structure, the unchecked memset operation executes.\nIf the fortify check were absent, the OOB write could allow for the corruption of adjacent kernel memory objects located on the stack or heap, potentially leading to arbitrary kernel code execution or privilege escalation. The current behavior ensures that the kernel panics, which serves as a defensive mechanism against unauthorized memory modification.\nThe vulnerable code component is the refcount tree management logic in OCFS2, specifically the transition logic in ocfs2_remove_refcount_extent() which incorrectly manages the bounds of the rf_records buffer when the tree depth is zero.\nAccess requirements include the ability to perform filesystem operations (unlink) on a mounted OCFS2 volume. While this requires local access, the impact is significant due to the nature of kernel-level vulnerabilities."
}