linux-cve-announce - CVE-2023-54276: nfsd: move init of percpu reply_cache_stats counters back to nfsd_init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025123002-CVE-2023-54276-06b4@gregkh>
Date: Tue, 30 Dec 2025 13:20:42 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2023-54276: nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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

nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net

Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd
startup") moved the initialization of the reply cache into nfsd startup,
but didn't account for the stats counters, which can be accessed before
nfsd is ever started. The result can be a NULL pointer dereference when
someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still
shut down.

This is a regression and a user-triggerable oops in the right situation:

- non-x86_64 arch
- /proc/fs/nfsd is mounted in the namespace
- nfsd is not started in the namespace
- unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"

Although this is easy to trigger on some arches (like aarch64), on
x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the
fixed_percpu_data. That struct looks just enough like a newly
initialized percpu var to allow nfsd_reply_cache_stats_show to access
it without Oopsing.

Move the initialization of the per-net+per-cpu reply-cache counters
back into nfsd_init_net, while leaving the rest of the reply cache
allocations to be done at nfsd startup time.

Kudos to Eirik who did most of the legwork to track this down.

The Linux kernel CVE team has assigned CVE-2023-54276 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 6.3 with commit f5f9d4a314da88c0a5faa6d168bf69081b7a25ae and fixed in 6.4.4 with commit 768c408594b52d8531e1a8ab62e5620c19213e73
	Issue introduced in 6.3 with commit f5f9d4a314da88c0a5faa6d168bf69081b7a25ae and fixed in 6.5 with commit ed9ab7346e908496816cffdecd46932035f66e2e

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-54276
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	fs/nfsd/cache.h
	fs/nfsd/nfscache.c
	fs/nfsd/nfsctl.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/3025d489f9c8984d1bf5916c4a20097ed80fca5c
	https://git.kernel.org/stable/c/8549384d0f65981761fe2077d04fa2a8d37b54e0
	https://git.kernel.org/stable/c/66a178177b2b3bb1d71e854c5e7bbb320eb0e566
	https://git.kernel.org/stable/c/768c408594b52d8531e1a8ab62e5620c19213e73
	https://git.kernel.org/stable/c/ed9ab7346e908496816cffdecd46932035f66e2e