Re: [PATCH 2/4] s390/mm: Add __context_unsafe() attribute to do_secure_storage_access()

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Using find_vma() instead of vma_lookup() in do_secure_storage_acce=
ss() allows an unprivileged user to trigger a WARN_ON_ONCE if a secure stor=
age access exception races with an unmap operation or occurs on an unmapped=
 address.
--

--- Patch [2]: [PATCH 2/4] s390/mm: Add __context_unsafe() attribute to do_=
secure_storage_access() ---
commit 679818f3abe10b8b5132294910a12a6eb003e99e
Author: Heiko Carstens <[email protected]>

s390/mm: Add __context_unsafe() attribute to do_secure_storage_access()

This commit disables context analysis for do_secure_storage_access() by add=
ing
the __context_unsafe() attribute. This prevents a warning during compilation
about releasing a spinlock that wasn't held, which occurs because
folio_walk_end() is a macro and lacks the necessary context analysis attrib=
ute.

> diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> index 028aeb9c48d6f..5af448fca9623 100644
> --- a/arch/s390/mm/fault.c
> +++ b/arch/s390/mm/fault.c
> @@ -406,6 +406,7 @@ NOKPROBE_SYMBOL(do_dat_exception);
>  #if IS_ENABLED(CONFIG_KVM)
> =20
>  void do_secure_storage_access(struct pt_regs *regs)
> +__context_unsafe(/* folio_walk_end() not instrumented */)
>  {

[Severity: High]
This isn't a bug introduced by this patch, but could this function trigger a
WARN_ON_ONCE that is reachable by unprivileged users?

Later in do_secure_storage_access(), find_vma() is called instead of
vma_lookup():

arch/s390/mm/fault.c:do_secure_storage_access() {
        ...
		mmap_read_lock(mm);
		vma =3D find_vma(mm, addr);
		if (!vma)
			return handle_fault_error(regs, SEGV_MAPERR);
		folio =3D folio_walk_start(&fw, vma, addr, 0);
        ...
}

If a secure storage access exception races with an unmap operation via munm=
ap(),
or occurs on an unmapped address, find_vma() returns the next VMA in the ad=
dress
space where vma->vm_start > addr.

When this VMA is passed to folio_walk_start(), it hits the explicit
WARN_ON_ONCE(addr < vma->vm_start || addr >=3D vma->vm_end) check.

With panic_on_warn enabled, could this allow an unprivileged process
manipulating its own memory to cause a denial of service?

>  	union teid teid =3D { .val =3D regs->int_parm_long };
>  	unsigned long addr =3D get_fault_address(regs);

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803172144.8270=
[email protected]?part=3D2