CVE-2025-71105

#!/bin/bash # CVE-2025-71105 PoC - f2fs slab cache race condition # This script demonstrates the slab cache conflict issue in f2fs # Prerequisites: f2fs filesystem tools and kernel module # Create two f2fs formatted partitions (/dev/vdb and /dev/vdc) # Step 1: Mount first f2fs partition mount /dev/vdb /mnt1 # Step 2: Mount second f2fs partition mount /dev/vdc /mnt2 # Step 3: Unmount first partition umount /mnt1 # Step 4: Remount first partition - this triggers the warning # Expected: "kmem_cache of name 'f2fs_xattr_entry-7:7' already exists" mount /dev/vdb /mnt1 # Check dmesg for the warning: # dmesg | grep -i "kmem_cache.*already exists" # Cleanup umount /mnt1 umount /mnt2

{"cve": {"id": "CVE-2025-71105", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "published": "2026-01-14T15:15:59.533", "lastModified": "2026-03-25T18:55:20.767", "vulnStatus": "Analyzed", "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: use global inline_xattr_slab instead of per-sb slab cache\n\nAs Hong Yun reported in mailing list:\n\nloop7: detected capacity change from 0 to 131072\n------------[ cut here ]------------\nkmem_cache of name 'f2fs_xattr_entry-7:7' already exists\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nRIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCall Trace:\n __kmem_cache_create include/linux/slab.h:353 [inline]\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]\n f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843\n f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918\n get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692\n vfs_get_tree+0x43/0x140 fs/super.c:1815\n do_new_mount+0x201/0x550 fs/namespace.c:3808\n do_mount fs/namespace.c:4136 [inline]\n __do_sys_mount fs/namespace.c:4347 [inline]\n __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug can be reproduced w/ below scripts:\n- mount /dev/vdb /mnt1\n- mount /dev/vdc /mnt2\n- umount /mnt1\n- mounnt /dev/vdb /mnt1\n\nThe reason is if we created two slab caches, named f2fs_xattr_entry-7:3\nand f2fs_xattr_entry-7:7, and they have the same slab size. Actually,\nslab system will only create one slab cache core structure which has\nslab name of \"f2fs_xattr_entry-7:3\", and two slab caches share the same\nstructure and cache address.\n\nSo, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will\ndecrease reference count of slab cache, rather than release slab cache\nentirely, since there is one more user has referenced the cache.\n\nThen, if we try to create slab cache w/ name \"f2fs_xattr_entry-7:3\" again,\nslab system will find that there is existed cache which has the same name\nand trigger the warning.\n\nLet's changes to use global inline_xattr_slab instead of per-sb slab cache\nfor fixing."}, {"lang": "es", "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nf2fs: usar inline_xattr_slab global en lugar de caché de slab por sb\n\nComo Hong Yun informó en la lista de correo:\n\nloop7: capacidad detectada cambió de 0 a 131072\n------------[ cortar aquí ]------------\nkmem_cache de nombre 'f2fs_xattr_entry-7:7' ya existe\nAdvertencia: CPU: 0 PID: 24426 en mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nAdvertencia: CPU: 0 PID: 24426 en mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 No contaminado 6.17.0-rc4 #1 PREEMPT(full)\nNombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nRIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nTraza de llamada:\n __kmem_cache_create include/linux/slab.h:353 [inline]\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]\n f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843\n f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918\n get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692\n vfs_get_tree+0x43/0x140 fs/super.c:1815\n do_new_mount+0x201/0x550 fs/namespace.c:3808\n do_mount fs/namespace.c:4136 [inline]\n __do_sys_mount fs/namespace.c:4347 [inline]\n __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nEl error puede ser reproducido con los siguientes scripts:\n- mount /dev/vdb /mnt1\n- mount /dev/vdc /mnt2\n- umount /mnt1\n- mounnt /dev/vdb /mnt1\n\nLa razón es si creamos dos cachés de slab, llamadas f2fs_xattr_entry-7:3 y f2fs_xattr_entry-7:7, y tienen el mismo tamaño de slab. En realidad, el sistema de slab solo creará una estructura central de caché de slab que tiene el nombre de slab \"f2fs_xattr_entry-7:3\", y dos cachés de slab comparten la misma estructura y dirección de caché.\n\nEntonces, si destruimos la caché f2fs_xattr_entry-7:3 con la dirección de caché, disminuirá el conteo de referencias de la caché de slab, en lugar de liberar ... (truncated)