Re: [RFC PATCH] arm64: mm: recover from kernel-mode SEA via exception table

[Will Deacon <will@kernel.org>]

On Sat, Sep 12, 2026 at 08:55:46PM +0700, Nguyen Ngoc Thang wrote:
> do_sea() unconditionally calls die() for a synchronous external
> abort taken at EL1, without ever consulting the exception table.
> This is inconsistent with __do_kernel_fault(), which does check
> fixup_exception() before giving up.
> 
> A SEA at EL1 is reachable and recoverable: futex's LL/SC atomic ops
> (__llsc_futex_cmpxchg/__llsc_futex_atomic_*) carry
> _ASM_EXTABLE_UACCESS_ERR entries, but if the user address is mapped
> to Device memory (e.g. a PCI BAR obtained via sysfs "resourceN" and
> mmap'd MAP_FIXED), the LDXR/STLXR pair faults with a SEA instead of
> a translation fault, and the extable fixup is never reached, so the
> kernel oopses instead of returning -EFAULT to userspace.
> 
> Check fixup_exception() for kernel-mode SEAs before dying, mirroring
> __do_kernel_fault(). No taint is added on the recovered path since
> this is a userspace-triggerable condition, not a hardware failure;
> a ratelimited warning keeps a trace of it.
> 
> Reported-by: syzbot+635d160c0d4133481520@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=635d160c0d4133481520
> Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
> ---
> Sent as RFC: verified by code inspection (ESR/DFSC decode matches
> the extable-carrying LL/SC futex path) but not yet reproduced under
> QEMU on my end; would appreciate a look before I chase the aarch64
> repro further.
> 
>  arch/arm64/mm/fault.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

I guess this is trying to solve same issue that was reported here:

https://lore.kernel.org/all/apsIH2hDpeiGiazJ@willie-the-truck/

however, I suspect you don't have to try too hard to make the abort
asynchronous and then this won't help. At least, if we want to go down
this route (or having a fixup), we need a way to guarantee that these
things are always synchronous.

Will