From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f74.google.com (mail-oo1-f74.google.com [209.85.161.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5ACC38C42E for ; Tue, 26 May 2026 20:50:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779828657; cv=none; b=JWyCsHr75b/GlDARVCjj7IunJRrKh7aoN0hZ7sSxN812HBox7wvYWTDuHxk8rl2X0+UKKlWsM0c8GiyP3O43tlzo50QvCJGgR0njiSkBuB3OUG01iSpbUP9WbyCUIOGjXm2YUl6KrHN7K/0mIa6C7obYbg2G+bAENU0Oh8vQRv0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779828657; c=relaxed/simple; bh=0TYW5BqkkS32o7ET9R9aBrP4LiKehhAcU+bX+Vk+Avs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=hry/9ucVn91mUxXe2x2OxFQqy0XdexArwULXE5CKSNFF/xML0At4+QLpGwLvHEj5EaGtNgvSgey7snXVjO4Tvq1oYPnCjYsPjKsSe87G9KJ4Nr6BoK+Vmhc0M2u0jGOffJarhcIQrKGaPUPuXcGBPu3Pw+JVu3MXIRGNck2UcYU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--avagin.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=PwaHQ6Hg; arc=none smtp.client-ip=209.85.161.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--avagin.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="PwaHQ6Hg" Received: by mail-oo1-f74.google.com with SMTP id 006d021491bc7-69db0927573so3323673eaf.1 for ; Tue, 26 May 2026 13:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779828655; x=1780433455; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=g4JLWLHFZ4VAwkmrRbZrIwjkAWpOIB54DvklYIirz08=; b=PwaHQ6HgLQblx6ZEhpc8ttn2BlpmqMaMPhFbPIG+9FGZePZCBlKRJezbHNUgvuI9Mh 80rC8CgMNpdwC7jKmc59PwxWGXe8fftSd5BrL5sJbC8I7Nl/mEm0kGTJ/YbEpeXHLnB1 bwlVX55pHQH73y+rRrYwz4hV9cglLTOzkwed/5qELqqq0XLDEvm/S+Qb9GtJjIqL5LFs aLSX4vXDLtXmfRxlVY5xbUuiKJBgVj/g1nnqvMYPbgDrhSCueljr30s7f3SdqKEzn4+d kswZR7tiBubh+C3DGbz6Xx/yVY9wrf63XP+lxCffXfsFc2cFkYnKJvGGcFnamrqjfSM8 LM8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779828655; x=1780433455; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g4JLWLHFZ4VAwkmrRbZrIwjkAWpOIB54DvklYIirz08=; b=W7p3R+74t8gCDwKHlQjkLj1LmhFJblaJ1WWGPYjWU6kN4bV09xfZZa5T6H6g2Rk0de wJmcyD/qhy2pFvqtPrJcPF46yQHzIbkep6gzoKtFyOuvNmEVjHgZSaFYHY1L+BZsPl/x 7vmS3a+5xStFJNhf7TjjzhCaCuh0lY6e6wjpWrycsW0Zevi/o9nKhzWo7azSbadkfQk5 xVlrgLDVISMbpyVnJXsWp3vvlTAj2M6cUupsqA8uasTxWOuLS5f7i3OqC6lpCiFZUhcY ulEuuEcthX7VDjUhV8UF2LeVf3nCv1x49iV0c4ss1sUlXSFdG9wvbT5KXPVn90eT1Xy7 w7yA== X-Gm-Message-State: AOJu0Yw0cyiEj5xgWniVq/9bwDMNX2EvyT5s3WtYI3MTbVKPbZWSMlME B9EXtRYR7jyaW92wWqH9Haj9sf7xbX2YgS+9qu/VH8vzsvcWhQLjVFkoiHKUs4QHdl3L2hW+CAH Ks7VgOg== X-Received: from ilfl18.prod.google.com ([2002:a92:2812:0:b0:500:25fd:8e65]) (user=avagin job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6820:16ac:b0:69d:8cf6:2e5a with SMTP id 006d021491bc7-69d8cf635acmr8341465eaf.23.1779828654411; Tue, 26 May 2026 13:50:54 -0700 (PDT) Date: Tue, 26 May 2026 20:50:43 +0000 In-Reply-To: <20260526205047.3339490-1-avagin@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260526205047.3339490-1-avagin@google.com> X-Mailer: git-send-email 2.54.0.746.g67dd491aae-goog Message-ID: <20260526205047.3339490-2-avagin@google.com> Subject: [PATCH 1/5] Revert "x86/fpu: Refine and simplify the magic number check during signal return" From: Andrei Vagin To: Thomas Gleixner , Ingo Molnar Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev, Borislav Petkov , Dave Hansen , x86@kernel.org, Andrei Vagin , "H. Peter Anvin" , "Chang S. Bae" , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" This reverts commit dc8aa31a7ac2 ("x86/fpu: Refine and simplify the magic number check during signal return"). The reverted commit broke applications that construct signal frames in userspace (such as CRIU and gVisor) if the frame's xstate size is smaller than the kernel's fpstate->user_size. Furthermore, this introduces a critical issue for checkpoint/restore tools like CRIU. If a process is checkpointed while inside a signal handler, its stack contains a signal frame formatted according to the source host's xstate capabilities. If that process is later restored on a destination host with larger xstate capabilities (e.g., a newer CPU with more features enabled, resulting in a larger fpstate->user_size), the kernel will look for FP_XSTATE_MAGIC2 at the destination host's larger user_size offset instead of the offset encoded in the frame's fx_sw->xstate_size. This causes the magic2 check to fail, forcing sigreturn to silently fall back to "FX-only" mode. Upon return from the signal handler, the process's extended state is reset to initial values instead of being restored, leading to silent data corruption. The original commit cited commit d877550eaf2d ("x86/fpu: Stop relying on userspace for info to fault in xsave buffer") as justification to stop relying on userspace for the magic number check. However, these two changes are fundamentally different. The last one only changed how much memory the kernel ensures is paged-in before running XRSTOR to prevent an infinite loop. It did not change the signal frame format or how the layout is validated. Reverting this change restores the use of fx_sw->xstate_size for locating magic2 and restores the necessary sanity checks, ensuring that the signal frame remains self-describing and portable. Cc: stable@vger.kernel.org Acked-by: Chang S. Bae Fixes: dc8aa31a7ac2 ("x86/fpu: Refine and simplify the magic number check during signal return") Signed-off-by: Andrei Vagin --- arch/x86/kernel/fpu/signal.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index c3ec2512f2bb..20b638c507ca 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -27,14 +27,19 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *fxbuf, struct _fpx_sw_bytes *fx_sw) { + int min_xstate_size = sizeof(struct fxregs_state) + + sizeof(struct xstate_header); void __user *fpstate = fxbuf; unsigned int magic2; if (__copy_from_user(fx_sw, &fxbuf->sw_reserved[0], sizeof(*fx_sw))) return false; - /* Check for the first magic field */ - if (fx_sw->magic1 != FP_XSTATE_MAGIC1) + /* Check for the first magic field and other error scenarios. */ + if (fx_sw->magic1 != FP_XSTATE_MAGIC1 || + fx_sw->xstate_size < min_xstate_size || + fx_sw->xstate_size > x86_task_fpu(current)->fpstate->user_size || + fx_sw->xstate_size > fx_sw->extended_size) goto setfx; /* @@ -43,7 +48,7 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *fxbuf, * fpstate layout with out copying the extended state information * in the memory layout. */ - if (__get_user(magic2, (__u32 __user *)(fpstate + x86_task_fpu(current)->fpstate->user_size))) + if (__get_user(magic2, (__u32 __user *)(fpstate + fx_sw->xstate_size))) return false; if (likely(magic2 == FP_XSTATE_MAGIC2)) -- 2.54.0.746.g67dd491aae-goog