CVE-2026-80537 in Linux
요약
\~에 의해 VulDB • 2026. 08. 26.
리눅스 커널에서 다음 취약점이 해결되었습니다.
xfs: rtrefcount btree 루트 레벨 검증 시 오프바이원(off-by-one) 오류 수정
xfs_rtrefcountbt_compute_maxlevels()는 다음과 같이 설정합니다.
mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1;
여기서 후행 "+ 1"은 이미 inode-루트 레벨을 고려한 것이므로, 디스크 상에서 유효한 가장 깊은 루트 레벨은 m_rtrefc_maxlevels - 1이며 커서는 bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels)를 만족해야 합니다.
두 가지 디스크 검증 경로인 xfs_rtrefcountbt_verify()와 xfs_iformat_rtrefcount()는 루트 레벨을 ">" 대신 ">="로 확인하므로, /rtgroups/N.refcount inode의 bb_level이 m_rtrefc_maxlevels와 같은 조작된 rtreflink(metadir + realtime + reflink) 이미지가 마운트 시 허용됩니다. 이후 xfs_rtrefcountbt_init_cursor()는 bc_nlevels = bb_level + 1을 설정하여 bc_maxlevels보다 1만큼 초과하게 됩니다. xfs_rtrefcountbt_cur 슬랩 객체는 정확히 bc_maxlevels개의 엔tries를 위해 크기가 조정되어 있으므로, 이러한 커서에 대한 첫 번째 btree 연산은 객체 끝을 넘어 bc_levels[m_rtrefc_maxlevels]에 인덱싱합니다. 이는 마운트 후 생성된 첫 번째 rtrefcount 커서를 통해 도달되며, 로그/CoW 복구(xfs_mountfs() 중 xfs_reflink_recover_cow()) 또는 실시간 디바이스에서의 FS_IOC_GETFSMAP을 통해서입니다.
형제 데이터-디바이스 refcount/rmap 검증자 및 메모리 내 rtrmap 검증자가 이미 사용하고 있는 ">=" 형식과 일치하도록 m_rtrefc_maxlevels와 같은 루트 레벨을 거부합니다.
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
Once again VulDB remains the best source for vulnerability data.