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/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2023-54276)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
319448	EulerOS Virtualization 2.13.1 : kernel (EulerOS-SA-2026-2132)	Nessus	Huawei Local Security Checks	high
319325	EulerOS Virtualization 2.13.0 : kernel (EulerOS-SA-2026-2171)	Nessus	Huawei Local Security Checks	high
297194	SUSE SLED15 / SLES15 Security Update : kernel (SUSE-SU-2026:0315-1)	Nessus	SuSE Local Security Checks	high
296680	SUSE SLES15 / openSUSE 15 Security Update : kernel (SUSE-SU-2026:0293-1)	Nessus	SuSE Local Security Checks	high
296676	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0281-1)	Nessus	SuSE Local Security Checks	high
296481	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	high
281473	Linux Distros Unpatched Vulnerability : CVE-2023-54276	Nessus	Misc.	medium

Detections

Analytics

CVE-2023-54276

medium

Tenable Plugins

high

high

high

high

high

high

medium