CVE-2026-80537: xfs: fix off-by-one in rtrefcount btree root level validation

Published Aug 26, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

xfs: fix off-by-one in rtrefcount btree root level validation

xfsrtrefcountbtcomputemaxlevels() sets

mp->mrtrefcmaxlevels = min(dmaxlevels, rmaxlevels) + 1;

where the trailing "+ 1" already accounts for the inode-root level, so the deepest valid on-disk root level is mrtrefcmaxlevels - 1 and a cursor must satisfy bcnlevels <= bcmaxlevels (= mrtrefcmaxlevels).

The two on-disk validation paths, xfsrtrefcountbtverify() and xfsiformatrtrefcount(), check the root level with ">" instead of ">=", so a crafted rtreflink (metadir + realtime + reflink) image whose /rtgroups/N.refcount inode has bblevel == mrtrefcmaxlevels is accepted on mount. xfsrtrefcountbtinitcursor() then sets bcnlevels = bblevel + 1, exceeding bcmaxlevels by one. Since the xfsrtrefcountbtcur slab object is sized for exactly bcmaxlevels entries, the first btree op on such a cursor indexes bclevels[mrtrefcmaxlevels] past the end of the object. This is reached by the first rtrefcount cursor built after mount, via log/CoW recovery (xfsreflinkrecovercow() during xfsmountfs()) or an FSIOCGETFSMAP over the realtime device.

Reject a root level equal to mrtrefcmaxlevels, 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 xfsbtreelookup (fs/xfs/libxfs/xfsbtree.c:2101) Write of size 2 at addr ffff888018391658 by task exploit/144 xfsbtreelookup (fs/xfs/libxfs/xfsbtree.c:2101) xfsbtreequeryrange (fs/xfs/libxfs/xfsbtree.c:5308) xfsrefcountrecovercowleftovers (fs/xfs/libxfs/xfsrefcount.c:2113) xfsreflinkrecovercow (fs/xfs/xfsreflink.c:1085) xlogrecoverfinish (fs/xfs/xfslogrecover.c:3551) xfsmountfs (fs/xfs/xfsmount.c:1158) xfsfsfillsuper (fs/xfs/xfssuper.c:1940) gettreebdevflags (fs/super.c:1634) vfsgettree (fs/super.c:1694) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121) The buggy address belongs to the cache xfsrtrefcountbtcur 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

Affected Software

1 affected component
Linux Kernel

Event History

Aug 26, 2026
CVE Published
via MITRE·02:37 PM
Data Sourced
via MITRE·02:37 PM
Description
Data Sourced
via NVD·03:17 PM
Description

Frequently Asked Questions

1

Which XFS filesystems are affected by this condition?

The affected filesystem image must use rtreflink, which requires metadata directories, realtime support, and reflink support. The malformed object is the /rtgroups/N.refcount inode on that image.

2

What must happen for the out-of-bounds access to be reached?

A crafted image with a refcount btree root level equal to m_rtrefc_maxlevels must be accepted during mount. The first rtrefcount cursor operation after mount can then index one entry beyond the cursor's allocated level array.

3

Can the issue be triggered without waiting for normal filesystem activity?

Yes. The description identifies log/CoW recovery during xfs_mountfs() as one path, and FS_IOC_GETFSMAP over the realtime device as another path that builds the affected cursor.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203