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>,
Fushuai Wang <wangfushuai@baidu.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH v3 1/2] x86/fpu: Fix NULL dereference in avx512_status()
Date: Wed, 23 Jul 2025 18:34:21 -0700 [thread overview]
Message-ID: <20250724013422.307954-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 in this case, since the access isn't
intended for modifying the FPU state. All kernel threads (except the
init_task) have a "struct fpu" with an accessible avx512_timestamp
variable. 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.
Another 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.
Update the ABI for kernel threads and do not report AVX-512 usage for
them. Not having a value in the file 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
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>
---
v3:
- Do not report anything for kernel threads. (DaveH)
- Make the commit message more precise.
v2: https://lore.kernel.org/lkml/20250721215302.3562784-1-sohil.mehta@intel.com/
- 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 9aa9ac8399ae..b90b2eec8fb8 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1855,19 +1855,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. */
+ 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-07-24 1:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 1:34 Sohil Mehta [this message]
2025-07-24 1:34 ` [PATCH v3 2/2] x86/fpu: Update the debug flow for x86_task_fpu() Sohil Mehta
2025-08-08 3:26 ` Lai, Yi
2025-08-08 7:49 ` Oleg Nesterov
2025-08-08 13:59 ` Sohil Mehta
2025-08-08 15:11 ` Oleg Nesterov
2025-08-08 18:52 ` Sohil Mehta
2025-08-12 12:57 ` Oleg Nesterov
2025-08-14 1:00 ` Sohil Mehta
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=20250724013422.307954-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=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=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®