CVE-2025-71105

Source
https://cve.org/CVERecord?id=CVE-2025-71105
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-71105.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2025-71105
Downstream
Related
Published
2026-01-14T15:05:54.510Z
Modified
2026-03-20T12:46:37.085712Z
Summary
f2fs: use global inline_xattr_slab instead of per-sb slab cache
Details

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

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

As Hong Yun reported in mailing list:

loop7: detected capacity change from 0 to 131072 ------------[ cut here ]------------ kmemcache of name 'f2fsxattrentry-7:7' already exists WARNING: CPU: 0 PID: 24426 at mm/slabcommon.c:110 kmemcachesanitycheck mm/slabcommon.c:109 [inline] WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmemcachecreateargs+0xa6/0x320 mm/slabcommon.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:kmemcachesanitycheck mm/slabcommon.c:109 [inline] RIP: 0010:__kmemcachecreateargs+0xa6/0x320 mm/slabcommon.c:307 Call Trace:  __kmemcachecreate include/linux/slab.h:353 [inline]  f2fskmemcachecreate fs/f2fs/f2fs.h:2943 [inline]  f2fsinitxattrcaches+0xa5/0xe0 fs/f2fs/xattr.c:843  f2fsfillsuper+0x1645/0x2620 fs/f2fs/super.c:4918  gettreebdevflags+0x1fb/0x260 fs/super.c:1692  vfsgettree+0x43/0x140 fs/super.c:1815  donewmount+0x201/0x550 fs/namespace.c:3808  domount fs/namespace.c:4136 [inline]  __dosysmount fs/namespace.c:4347 [inline]  __sesysmount+0x298/0x2f0 fs/namespace.c:4324  dosyscallx64 arch/x86/entry/syscall64.c:63 [inline]  dosyscall64+0x8e/0x3a0 arch/x86/entry/syscall64.c:94  entrySYSCALL64afterhwframe+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 f2fsxattrentry-7:3 and f2fsxattrentry-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 "f2fsxattrentry-7:3", and two slab caches share the same structure and cache address.

So, if we destroy f2fsxattrentry-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 "f2fsxattrentry-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 inlinexattrslab instead of per-sb slab cache for fixing.

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/71xxx/CVE-2025-71105.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
a999150f4fe3abbb7efd05411fd5b460be699943
Fixed
93d30fe19660dec6bf1bd3d5c186c1c737b21aa5
Fixed
474cc3ed37436ddfd63cac8dbffe3b1e219e9100
Fixed
72ce19dfed162da6e430467333b2da70471d08a4
Fixed
be4c3a3c6c2304a8fcd14095d18d26f0cc4e222a
Fixed
1eb0b130196bcbc56c5c80c83139fa70c0aa82c5
Fixed
e6d828eae00ec192e18c2ddaa2fd32050a96048a
Fixed
1f27ef42bb0b7c0740c5616ec577ec188b8a1d05

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-71105.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.7.0
Fixed
5.10.248
Type
ECOSYSTEM
Events
Introduced
5.11.0
Fixed
5.15.198
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
6.1.160
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.120
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.12.64
Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
6.18.3

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-71105.json"