From: Sohil Mehta <sohil.mehta@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org
Cc: Borislav Petkov <bp@alien8.de>, "H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@intel.com>,
Sohil Mehta <sohil.mehta@intel.com>,
Sean Christopherson <seanjc@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Vignesh Balasubramanian <vigbalas@amd.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Oleg Nesterov <oleg@redhat.com>,
"Chang S . Bae" <chang.seok.bae@intel.com>,
Brian Gerst <brgerst@gmail.com>,
Eric Biggers <ebiggers@google.com>, Kees Cook <kees@kernel.org>,
Chao Gao <chao.gao@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Fushuai Wang <wangfushuai@baidu.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v4] x86/fpu: Fix NULL dereference in avx512_status()
Date: Mon, 11 Aug 2025 11:50:44 -0700 [thread overview]
Message-ID: <20250811185044.2227268-1-sohil.mehta@intel.com> (raw)
From: Fushuai Wang <wangfushuai@baidu.com>
Problem
-------
With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status
causes a kernel NULL pointer dereference.
Kernel threads aren't expected to access the FPU state directly. Kernel
usage of FPU registers is contained within kernel_fpu_begin()/_end()
sections.
However, to report AVX-512 usage, the avx512_timestamp variable within
struct fpu needs to be accessed, which triggers a warning in
x86_task_fpu().
For Kthreads:
proc_pid_arch_status()
avx512_status()
x86_task_fpu() => Warning and returns NULL
x86_task_fpu()->avx512_timestamp => NULL dereference
The warning is a false alarm since the access isn't intended for
modifying the FPU state. All kernel threads (except the init_task) have
a "struct fpu" with an avx512_timestamp variable that is valid to
access. Also, the init_task (PID 0) never follows this path since it is
not exposed in /proc.
Solution
--------
One option is to get rid of the warning in x86_task_fpu() for kernel
threads. However, that warning was recently added and might be useful to
catch any potential misuse of the FPU state in kernel threads.
A better option is to avoid the access altogether. The kernel does not
track AVX-512 usage for kernel threads.
save_fpregs_to_fpstate()->update_avx_timestamp() is never invoked for
kernel threads, so avx512_timestamp is always guaranteed to be 0.
Also, the legacy behavior of reporting "AVX512_elapsed_ms: -1", which
signifies "no AVX-512 usage", is misleading. The kernel usage just isn't
tracked.
For now, update the ABI for kernel threads and do not report AVX-512
usage for them. Reading /proc/[kthread]/arch_status would display no
AVX-512 information. This avoids the NULL dereference as well as the
misleading report.
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Fixes: 22aafe3bcb67 ("x86/fpu: Remove init_task FPU state dependencies, add debugging warning for PF_KTHREAD tasks")
Cc: <stable@vger.kernel.org> # v6.15+
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Co-developed-by: Sohil Mehta <sohil.mehta@intel.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v4:
- No significant change, minor wording improvements.
v3: https://lore.kernel.org/lkml/20250724013422.307954-1-sohil.mehta@intel.com/
- Do not report anything for kernel threads. (DaveH)
- Make the commit message more precise.
v2:
- Avoid making the fix dependent on CONFIG_X86_DEBUG_FPU.
- Include PF_USER_WORKER in the kernel thread check.
- Update commit message for clarity.
---
arch/x86/kernel/fpu/xstate.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 12ed75c1b567..28e4fd65c9da 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1881,19 +1881,20 @@ long fpu_xstate_prctl(int option, unsigned long arg2)
#ifdef CONFIG_PROC_PID_ARCH_STATUS
/*
* Report the amount of time elapsed in millisecond since last AVX512
- * use in the task.
+ * use in the task. Report -1 if no AVX-512 usage.
*/
static void avx512_status(struct seq_file *m, struct task_struct *task)
{
- unsigned long timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp);
- long delta;
+ unsigned long timestamp;
+ long delta = -1;
- if (!timestamp) {
- /*
- * Report -1 if no AVX512 usage
- */
- delta = -1;
- } else {
+ /* AVX-512 usage is not tracked for kernel threads. Don't report anything. */
+ if (task->flags & (PF_KTHREAD | PF_USER_WORKER))
+ return;
+
+ timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp);
+
+ if (timestamp) {
delta = (long)(jiffies - timestamp);
/*
* Cap to LONG_MAX if time difference > LONG_MAX
--
2.43.0
next reply other threads:[~2025-08-11 18:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 18:50 Sohil Mehta [this message]
2025-08-11 19:22 ` [PATCH v4] x86/fpu: Fix NULL dereference in avx512_status() Dave Hansen
2025-08-11 20:16 ` Sohil Mehta
2025-08-11 20:29 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250811185044.2227268-1-sohil.mehta@intel.com \
--to=sohil.mehta@intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=chang.seok.bae@intel.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@google.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=vigbalas@amd.com \
--cc=wangfushuai@baidu.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.