Re: [PATCH 01/24] arm64: Fix lazy TCO clear when enabling user MTE

[Peter Collingbourne]

On Wed, Nov 11, 2026 at 12:57 AM Pierre-Clément Tosi <ptosi@xxxxxxxxxx> wrote:
>
> Hi Catalin,
>
> On Tue, Nov 10, 2026 at 06:33:20PM +0000, Catalin Marinas wrote:
> > On Sat, Nov 07, 2026 at 04:36:07PM +0100, Pierre-Clément Tosi wrote:
> > > On kernel entry from EL0 with HW KASAN inactive and user MTE disabled or
> > > in async mode, mte_disable_tco_entry() leaves PSTATE.TCO set to avoid an
> > > expensive write, as it assumes that EL1 tag checks are not needed.
> > >
> > > However, if the thread is in the process of enabling sync or asymm MTE,
> > > set_mte_ctrl() updates SCTLR_EL1.TCF0 without clearing PSTATE.TCO! As a
> > > result, kernel uaccesses miss tag faults until the next context switch.
> >
> > Nit: next context switch or another syscall. I think this makes it
> > clearer that the only potential missed tag accesses after the prctl() is
> > a signal frame write as we don't have other uaccesses.

Or any other kernel entry such as signal delivery.

> >
> > > Clear TCO in set_mte_ctrl() immediately after setting the task's SCTLR.
> > >
> > > Cc: Peter Collingbourne <peter@xxxxxxxxx>
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Fixes: 38ddf7dafaea ("arm64: mte: avoid clearing PSTATE.TCO on entry unless necessary")
> > > Signed-off-by: Pierre-Clément Tosi <ptosi@xxxxxxxxxx>
> >
> > The patch is correct but I wonder whether we need a cc stable.
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>
>
> Thanks for your review.
>
> I'm happy to drop the cc in the next version. The rationale was that this fixed
> an unexpected userspace-visible kernel behavior and closed a window during which
> tag checks were not performed, which _could_ be a concern when userspace enables
> MTE for security. I can see how this doesn't make a strong case for backporting.

I don't think this needs a cc stable.

I'm also skeptical that this is worth "fixing" at all. All that this
patch does is move the TCO disable slightly earlier in a way that is
almost unobservable except by sending a signal to a process at the
right time. So this patch only has a useful effect if it would
otherwise be somehow possible to compromise a process by taking
advantage of the kernel's signal frame write. Even then it doesn't
really help mitigate anything, it just makes the window of opportunity
slightly smaller.

Peter