CVE-2025-38232

NFSD: fix race between nfsd registration and exports_proc

State
Published
Severity
7.8 High
Published
Jul 4, 2025
Updated
Oct 15, 2026
Reserved
Apr 16, 2025

Read the record on cve.org

Description

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

NFSD: fix race between nfsd registration and exports_proc

As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd.

Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd

for 5.4 kernel ARM64:

CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0

CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010

PC is at : exports_net_open+0x50/0x68 [nfsd]

Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248

Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().

and same is happening on latest 6.14 kernel as well:

[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---

It reproduced simply with below script: while [ 1 ] do /exportfs -r done &

while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &

So exporting interfaces to user space shall be done at last and cleanup at first place.

With change there is no Kernel OOPs.

Scores

CVSSScoreVectorSource
3.17.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HLinux

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before 49b57b98fa601ae6cc7897bab4515129da8290f7Affected
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before 88d6785c173a7c4de05bef8c4fd8a9b42ead02d5Affected
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before 8120e420013d947c890f358f30a2d98ba8ac20bcAffected
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before 2029ca75cdfa6a25716a5a76b751486cce7e3822Affected
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before 327011a2bb4f7de9c72b891a96ce8d902828bddfAffected
  • bd5ae9288d6451bd346a1b4a59d4fe7e62ba29b7 to before f7fb730cac9aafda8b9813b55d04e28a9664d17cAffected
  • 8677e99150b0830d29cc1318b4cc559e176940bbAffected
  • 7c7cb07d4affcf41749234fe9dc4d90cd3959e32Affected
  • 4d41f65efeec0a6da6088341203c81e49ebfcd90Affected
  • 5.4.102 to before 5.5Affected
  • 5.10.20 to before 5.11Affected
  • 5.11.3 to before 5.12Affected
LinuxLinux
  • 5.12Affected
  • before 5.12Not affected
  • 5.15.199 through 5.15.*Not affected
  • 6.1.162 through 6.1.*Not affected
  • 6.6.122 through 6.6.*Not affected
  • 6.12.35 through 6.12.*Not affected
  • 6.15.4 through 6.15.*Not affected
  • 6.16 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.