<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 16:59:14 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-54276 — nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2023-54276</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net&lt;/p&gt;
&lt;p&gt;Commit f5f9d4a314da (&amp;#34;nfsd: move reply cache initialization into nfsd
startup&amp;#34;) moved the initialization of the reply cache into nfsd startup,
but didn&amp;#39;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.&lt;/p&gt;
&lt;p&gt;This is a regression and a user-triggerable oops in the right situation:&lt;/p&gt;
&lt;p&gt;- non-x86_64 arch
- /proc/fs/nfsd is mounted in the namespace
- nfsd is not started in the namespace
- unprivileged user calls &amp;#34;cat /proc/fs/nfsd/reply_cache_stats&amp;#34;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Kudos to Eirik who did most of the legwork to track this down.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net&lt;/p&gt;
&lt;p&gt;Commit f5f9d4a314da (&amp;#34;nfsd: move reply cache initialization into nfsd
startup&amp;#34;) moved the initialization of the reply cache into nfsd startup,
but didn&amp;#39;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.&lt;/p&gt;
&lt;p&gt;This is a regression and a user-triggerable oops in the right situation:&lt;/p&gt;
&lt;p&gt;- non-x86_64 arch
- /proc/fs/nfsd is mounted in the namespace
- nfsd is not started in the namespace
- unprivileged user calls &amp;#34;cat /proc/fs/nfsd/reply_cache_stats&amp;#34;&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Kudos to Eirik who did most of the legwork to track this down.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2023-54276</guid>
    </item>
  </channel>
</rss>
