CVE-2025-71105

EPSS 0.0%
  • Published: 2026-01-14T15:15:59.533

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

f2fs: use global inline_xattr_slab instead of per-sb slab cache

As Hong Yun reported in mailing list:

loop7: detected capacity change from 0 to 131072
————[ cut here ]————
kmem_cache of name ‘f2fs_xattr_entry-7:7’ already exists
WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]
WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307
CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]
RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307
Call Trace:
 __kmem_cache_create include/linux/slab.h:353 [inline]
 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]
 f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843
 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918
 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692
 vfs_get_tree+0x43/0x140 fs/super.c:1815
 do_new_mount+0x201/0x550 fs/namespace.c:3808
 do_mount fs/namespace.c:4136 [inline]
 __do_sys_mount fs/namespace.c:4347 [inline]
 __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The bug can be reproduced w/ below scripts:
– mount /dev/vdb /mnt1
– mount /dev/vdc /mnt2
– umount /mnt1
– mounnt /dev/vdb /mnt1

The reason is if we created two slab caches, named f2fs_xattr_entry-7:3
and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,
slab system will only create one slab cache core structure which has
slab name of “f2fs_xattr_entry-7:3”, and two slab caches share the same
structure and cache address.

So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will
decrease reference count of slab cache, rather than release slab cache
entirely, since there is one more user has referenced the cache.

Then, if we try to create slab cache w/ name “f2fs_xattr_entry-7:3” again,
slab system will find that there is existed cache which has the same name
and trigger the warning.

Let’s changes to use global inline_xattr_slab instead of per-sb slab cache
for fixing.

Related CVE by CWE

No related CWE found.

Top CVE for Vendor

No vendor taxonomy on this entry.

Recently Exploited Similar Vulnerabilities

No recent KEV-listed items for this vendor/product.

How to fix CVE-2025-71105

CVE-2025-71105 is a unknown severity vulnerability affecting the affected product.

Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: use global inline_xattr_slab instead of per-sb slab cache As Hong Yun reported in mailing list: loop7: detected capacity change from 0 to 131072 ————[ cut here ]———— kmem_cache of name ‘f2fs_xattr_entry-7:7’ already exists WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline] WARNING: […]

Exploit Difficulty: HARD
⏱️ Time to exploit: > 4 hours
🛠️ Required skills: Advanced security expertise
💰 Public exploits: Rare or not public

How to Fix:

1 Identify affected systems

- Check if you're running the affected product

2 Immediate actions

- Update to the latest patched version
- If patching is not immediately possible: restrict network exposure, apply least-privilege access

3 Verification

- Test the fix in a staging environment first
- Review logs for signs of exploitation
- Monitor for IOCs (Indicators of Compromise)

4 Long-term prevention

- Enable automatic security updates
- Set up vulnerability monitoring
- Review and harden security configurations

Exploit Difficulty Assessment

HARD
⏱️ Time to Exploit: > 4 hours
🛠️ Skills Required: Advanced security expertise
💰 Public Exploits: Rare or not public

Vulnerability Timeline

Jan 14, 2026
Vulnerability Published

CVE details first published to NVD database

Jan 14, 2026
Imported to Database

Added to this CVE tracking system

Detection Rules & IOCs

No specific detection rules generated for this vulnerability type.

No vendor/product data available.