Look up another CVE · open CVE-2026-97548 in the interactive tracker
CVE-2026-97548
xfs: fix the rtrmap and rtrefcount _maxlevels_ondisk functions
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem fs/xfs. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-97548 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The _maxlevels_ondisk functions are used to compute the size of in-memory btree cursors for each btree type. Unfortunately, LOLLM noticed that the rtrmap and rtrefcount versions of these functions forget to account for the inode root, which means that we could access beyond the end of the cursor given a sufficiently large btree. Fix this.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/xfs/libxfs/xfs_rtrefcount_btree.c
fs/xfs/libxfs/xfs_rtrmap_btree.c
- What this is
- XFS FILESYSTEMMAINTAINERS section matched on fs/xfs/ · linux-xfs@vger.kernel.org · Supported
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-09-25 (24 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/xfs
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.14 | 6.18.53 | 108114437915 |
| 6.14 | 7.2.7 | 84316cb25af9 |
| 6.14 | 7.3 | aa301322f72f |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The overflow is driven by on-disk XFS fields: sb_blocksize/sb_rgextents consumed by xfs_rtrefcountbt_compute_maxlevels() and the /rtgroups/N.refcount inode-root bb_level loaded by xfs_iformat_rtrefcount(). Entry is mount(2)→xfs_init_fs_context()→get_tree_bdev()→xfs_fs_fill_super()→xfs_mountfs()→xfs_log_mount_finish()→xlog_recover_finish()→xfs_reflink_recover_cow(); no NFS/SMB/TCP message carries bb_level.
- AC:LAttack complexity, low
- xfs_rtrefcountbt_maxlevels_ondisk() sizes the xfs_rtrefcountbt_cur slab for 6 bc_levels slots. A 1K-block rtreflink image with large sb_rgextents makes xfs_rtrefcountbt_compute_maxlevels() set m_rtrefc_maxlevels=7; xfs_iformat_rtrefcount() accepts bb_level=6, so xfs_rtrefcountbt_init_cursor() sets bc_nlevels=7 and xfs_btree_lookup() stores bc_levels[6].ptr. A dirty log makes xlog_recovery_needed() true so this runs on every mount; no race.
- PR:NPrivileges required, none
- Crafting the image needs no host account. xfs_fs_type.fs_flags is FS_REQUIRES_DEV|FS_ALLOW_IDMAP|FS_MGTIME|FS_LBS with no FS_USERNS_MOUNT, so mount_capable() is capable(CAP_SYS_ADMIN) in init_user_ns; that privileged mount of the attacker image is scored as UI:R, not attacker privilege.
- UI:RUser interaction, required
- xfs_rtrefcountbt_init_cursor() runs from xfs_refcount_recover_cow_leftovers() in xfs_reflink_recover_cow() during xlog_recover_finish() after xfs_fs_fill_super() attaches the attacker bdev. Because XFS is not FS_USERNS_MOUNT, a victim, automounter, or administrator must mount that image before the undersized cursor is built.
- S:UScope, unchanged
- The bc_levels[] store in xfs_btree_lookup() corrupts the xfs_rtrefcountbt_cur slab in the host kernel that mounted the volume; this is not a KVM/Xen guest-to-host escape or an IOMMU/DMA bypass.
- C:HConfidentiality impact, high
- xfs_btree_lookup() writes cur->bc_levels[level].ptr (uint16_t) at level=bc_nlevels-1 when the xfs_rtrefcountbt_cur object from xfs_rtrefcountbt_maxlevels_ondisk() has only 6 slots; that slab OOB write can disclose or influence adjacent heap objects.
- I:HIntegrity impact, high
- The same out-of-bounds store of bc_levels[6].ptr past the 6-slot xfs_rtrefcountbt_cur kmem_cache object is a kernel heap write into whatever follows the cursor, enabling adjacent-object corruption toward an arbitrary write or control-flow hijack.
- A:HAvailability impact, high
- xfs_btree_simple_query_range() calls xfs_btree_lookup() on that undersized cursor from xfs_refcount_recover_cow_leftovers() during mount recovery; indexing bc_levels[6] oopses or panics the host.