Re: [RFC PATCH v1 3/6] tee: optee: teach the memory type check about RISC-V page attributes

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Preexisting bug: `pte_pgprot()` produces corrupted memory types for non-PMA (e.g., I/O) memory on RISC-V T-Head systems, which can lead to invalid memory attributes being installed.
- [High] `__check_mem_type` does not verify VMA coverage, allowing a TOCTOU race to completely bypass the `is_normal_memory` check.
--

commit a7e70918fe97729d4caaa4509f60ba6abde233e2
Author: Marouene Boubakri <marouene.boubakri@oss.nxp.com>

tee: optee: teach the memory type check about RISC-V page attributes

This commit updates optee_check_mem_type() to verify memory types on RISC-V.
It ensures that registered memory is normal cacheable memory by checking if
the Svpbmt (or T-Head equivalent) bits encoded in the page attributes are
cleared.

> diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
> index e046aff618286..c29bff2248485 100644
> --- a/drivers/tee/optee/call.c
> +++ b/drivers/tee/optee/call.c
> @@ -604,6 +604,14 @@ static bool is_normal_memory(pgprot_t p)
>  #elif defined(CONFIG_ARM64)
>  	return ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL)) ||
>  	       ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED));
> +#elif defined(CONFIG_RISCV)
> +	/*
> +	 * Svpbmt, or the T-Head equivalent, encodes non-cacheable and I/O
> +	 * memory in the memory type bits of the PTE, normal cacheable memory
> +	 * (PMA) has them cleared. Without Svpbmt the memory type only comes
> +	 * from the PMAs, the mask is empty and all mappings pass the check.
> +	 */
> +	return !(pgprot_val(p) & _PAGE_MTMASK);

[Severity: High]
This isn't a bug introduced by this patch, but on RISC-V T-Head systems, can
pte_pgprot() produce corrupted memory types for non-PMA (e.g., I/O) memory?

Looking at pte_pgprot() in arch/riscv/include/asm/pgtable.h:

	return __pgprot(pte_val(pfn_pte(pfn, __pgprot(0))) ^ pte_val(pte));

The pte_pgprot() function XORs pte_val(pfn_pte(pfn, __pgprot(0))) with
pte_val(pte).

For T-Head systems, pfn_pte() implicitly sets _PAGE_PMA_THEAD via
ALT_THEAD_PMA if no memory type is present in the pgprot.

XORing this implicitly-added _PAGE_PMA_THEAD with an I/O mapping's
_PAGE_NOCACHE_THEAD yields a corrupted, invalid memory type mask (neither
valid PMA nor NOCACHE). Any path reusing or modifying page protection of an
existing I/O or device mapping on T-Head systems could expose the system to
architectural instability and data corruption due to invalid memory attributes
being installed.

Since this code relies on the memory type bits in pgprot_t p via
_PAGE_MTMASK, would this corruption affect the check here?

>  #else
>  #error "Unsupported architecture"
>  #endif

[Severity: High]
This is a pre-existing issue, but does __check_mem_type() fail to verify VMA
coverage, allowing a Time-of-Check to Time-of-Use (TOCTOU) race?

Looking at __check_mem_type() below in drivers/tee/optee/call.c:

	for_each_vma_range(vmi, vma, end) {
		if (!is_normal_memory(vma->vm_page_prot))
			return -EINVAL;
	}

If userspace maps non-normal memory (e.g., write-combined or device memory)
and invokes registration, could it concurrently unmap the region after the
pages are pinned (e.g., in tee_shm_register_user_buf()) but before
__check_mem_type() is called?

Because for_each_vma_range() silently skips holes, if the region is
completely unmapped, the loop wouldn't execute, and the function would return 0
(success).

This bypasses the memory type check and allows malicious userspace to register
non-normal memory with OP-TEE. OP-TEE would map it as Normal Cacheable memory,
causing a memory attribute mismatch that can trigger asynchronous external
aborts, system hangs, or cache coherency issues.

Are there missing VMA coverage checks to prevent unmapped regions with
still-pinned pages from passing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910012057.106966-1-marouene.boubakri@oss.nxp.com?part=3