Re: [PATCH 1/2] x86/fred: Reconstruct the #GP context for rejected INT instructions

Peter Zijlstra <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.kernel.stable
Message-ID <[email protected]>
On Thu, Sep 17, 2026 at 05:07:45PM -0700, H. Peter Anvin wrote:
> On 2026-09-17 16:09, Matthew Schwartz wrote:
> > FRED event delivery does not use the IDT, so the gate DPL check that
> > rejects a user INT n falls to software (Intel FRED specification [1],
> > section 8.3). fred_intx() rejects the same vectors as IDT delivery, but
> > reports a zero error code and the IP after the INT. This breaks the
> > signal ABI. Wine uses the error code to recognize INT 0x2d, so the
> > changed context turns a handled breakpoint into an access violation in
> > Elden Ring.
> > 
> > Rewind IP using the instruction length in the augmented SS and
> > synthesize the IDT selector error code, (vector << 3) | 2. Set RF in the
> > saved flags, as the CPU does for a #GP fault. Section 5.2.1 defines the
> > saved vector, instruction length and RF state. The supplied length
> > handles prefixes without reading user memory. Limit the changes to
> > already-rejected software interrupts, preserving the accepted INT3, INT4
> > and enabled INT80 paths and hardware exceptions. With IA32 emulation
> > disabled, INT 0x80 now reports the same #GP as the DPL 0 gate IDT
> > installs there. The rewound IP also stops fixup_iopl_exception() from
> > inspecting the byte after the INT.
> > 
> > Also clear the software event flag. Section 6.2.3 specifies that ERETU
> > with this flag and TF set traps before executing any user instruction. A
> > tracer that suppresses SIGSEGV and resumes with TF set expects the next
> > instruction to run first, as after IRET. The sigreturn path clears the
> > same flag for this reason in prevent_single_step_upon_eretu().
> > 
> > [1] Intel Flexible Return and Event Delivery (FRED) Specification,
> > revision 9.0 (346446-009US), sections 5.2.1, 6.2.3 and 8.3.
> > 
> > Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
> > Reported-by: Paul Gofman <[email protected]>
> > Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15745
> > Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16132
> > Signed-off-by: Matthew Schwartz <[email protected]>
> > Link: https://cdrdv2.intel.com/v1/dl/getContent/678938 # [1]
> 
> Reviewed-by: H. Peter Anvin <[email protected]>
> 
> This really should go into -stable.

It has a Fixes tag, afaik they really good at picking those up. Let me
go queue them in x86/urgent.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.