Description

In the Linux kernel, the following vulnerability has been resolved: xfs: fix off-by-one in rtrefcount btree root level validation xfs_rtrefcountbt_compute_maxlevels() sets mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1; where the trailing "+ 1" already accounts for the inode-root level, so the deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels). The two on-disk validation paths, xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1, exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is sized for exactly bc_maxlevels entries, the first btree op on such a cursor indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an FS_IOC_GETFSMAP over the realtime device. Reject a root level equal to m_rtrefc_maxlevels, matching the ">=" form already used by the sibling data-device refcount/rmap verifiers and the in-memory rtrmap verifier. BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101) xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308) xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113) xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085) xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551) xfs_mountfs (fs/xfs/xfs_mount.c:1158) xfs_fs_fill_super (fs/xfs/xfs_super.c:1940) get_tree_bdev_flags (fs/super.c:1634) vfs_get_tree (fs/super.c:1694) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216 The buggy address is located 8 bytes to the right of allocated 216-byte region [ffff888018391578, ffff888018391650) Kernel panic - not syncing: Fatal exception

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:07.890Z",
  "pubdate": "2026-08-26T15:17:07.890Z",
  "executiveSummary": "A critical memory safety vulnerability exists in the Linux kernel's XFS filesystem implementation regarding realtime refcount btree (rtrefcountbt) root level validation.\nThe vulnerability is a slab-out-of-bounds write occurring due to an off-by-one error in the validation logic for the btree root level.\nAn attacker capable of crafting a malicious XFS filesystem image containing a manipulated '/rtgroups/N.refcount' inode can trigger this flaw during the filesystem mount process or through subsequent btree operations.\nSuccessful exploitation results in memory corruption within the kernel slab allocator, which can be leveraged to cause a kernel panic (Denial of Service) or potentially facilitate arbitrary code execution with elevated privileges.\nThe flaw affects the XFS subsystem specifically in configurations utilizing realtime devices with reflink and metadir features enabled.\nAs this vulnerability is triggered during filesystem mounting or via specific ioctls like FS_IOC_GETFSMAP, an attacker requires the ability to supply or mount a maliciously crafted filesystem image to the victim system.",
  "technicalDetails": "The root cause of this vulnerability is an off-by-one logic error within the XFS realtime refcount btree validation functions, specifically xfs_rtrefcountbt_verify() and xfs_iformat_rtrefcount().\nThe system calculates the maximum tree depth via xfs_rtrefcountbt_compute_maxlevels(), where 'mp->m_rtrefc_maxlevels' is assigned a value that includes the inode-root level. The deepest valid on-disk level is intended to be 'm_rtrefc_maxlevels - 1'.\nValidation checks within the affected functions incorrectly use the '>' operator instead of the required '>=' operator when comparing the root level against 'm_rtrefc_maxlevels'. This allows an on-disk 'bb_level' equal to 'm_rtrefc_maxlevels' to pass verification.\nWhen a malicious image is mounted, the function xfs_rtrefcountbt_init_cursor() is invoked. It calculates the cursor's levels as 'bc_nlevels = bb_level + 1'. If 'bb_level' is equal to 'm_rtrefc_maxlevels', 'bc_nlevels' becomes 'm_rtrefc_maxlevels + 1'.\nThis calculation exceeds the size of the pre-allocated 'xfs_rtrefcountbt_cur' slab object, which is sized strictly for 'bc_maxlevels' entries. Consequently, subsequent btree operations—such as xfs_btree_lookup() triggered during log recovery or filesystem operations—index into memory beyond the bounds of the slab object.\nThe attack flow follows a predictable pattern: 1) The attacker constructs a filesystem image with a corrupted rtrefcount inode, setting 'bb_level' to exactly 'm_rtrefc_maxlevels'. 2) The system attempts to mount the filesystem or execute a recovery process like xfs_reflink_recover_cow(). 3) The verifier fails to reject the inode, allowing the kernel to initialize a cursor with an invalid 'bc_nlevels' value. 4) The next btree lookup operation performs an out-of-bounds write to the slab, resulting in memory corruption and a KASAN-detected crash.\nThis vulnerability is particularly dangerous as it can be triggered automatically during the mount sequence, providing a mechanism for an unprivileged local user or an entity capable of mounting external storage to crash the kernel or compromise system integrity."
}