diff options
| author | Vivian Wang <wangruikang@iscas.ac.cn> | 2026-03-03 13:29:46 +0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2026-07-04 13:44:20 +0200 |
| commit | 7643e5622994f9b207445f9cd89a02223ce6a99f (patch) | |
| tree | 369531ce6f5baaa329211b7e30ad87fe74b77671 | |
| parent | 3b33dbb43e21a8d1248dbe906d9e27f640a6001a (diff) | |
| download | linux-stable-7643e5622994f9b207445f9cd89a02223ce6a99f.tar.gz linux-stable-7643e5622994f9b207445f9cd89a02223ce6a99f.zip | |
riscv: kfence: Call mark_new_valid_map() for kfence_unprotect()
commit 8d6c8c40e733b3fcaf92fed0a078bba2f6941a3b upstream.
In kfence_protect_page(), which kfence_unprotect() calls, we cannot send
IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs
spuriously faulting on a recently allocated kfence object despite it
being valid, leading to false positive use-after-free reports.
Fix this by calling mark_new_valid_map() so that the page fault handling
code path notices the spurious fault and flushes TLB then retries the
access.
Update the comment in handle_exception to indicate that
new_valid_map_cpus_check also handles kfence_unprotect() spurious
faults.
Note that kfence_protect() has the same stale TLB entries problem, but
that leads to false negatives, which is fine with kfence.
Cc: stable@vger.kernel.org
Reported-by: Yanko Kaneti <yaneti@declera.com>
Fixes: b3431a8bb336 ("riscv: Fix IPIs usage in kfence_protect_page()")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://patch.msgid.link/20260303-handle-kfence-protect-spurious-fault-v2-2-f80d8354d79d@iscas.ac.cn
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| -rw-r--r-- | arch/riscv/include/asm/kfence.h | 7 | ||||
| -rw-r--r-- | arch/riscv/kernel/entry.S | 6 |
2 files changed, 9 insertions, 4 deletions
diff --git a/arch/riscv/include/asm/kfence.h b/arch/riscv/include/asm/kfence.h index d08bf7fb3aee..29cb3a6ee113 100644 --- a/arch/riscv/include/asm/kfence.h +++ b/arch/riscv/include/asm/kfence.h @@ -6,6 +6,7 @@ #include <linux/kfence.h> #include <linux/pfn.h> #include <asm-generic/pgalloc.h> +#include <asm/cacheflush.h> #include <asm/pgtable.h> static inline bool arch_kfence_init_pool(void) @@ -17,10 +18,12 @@ static inline bool kfence_protect_page(unsigned long addr, bool protect) { pte_t *pte = virt_to_kpte(addr); - if (protect) + if (protect) { set_pte(pte, __pte(pte_val(ptep_get(pte)) & ~_PAGE_PRESENT)); - else + } else { set_pte(pte, __pte(pte_val(ptep_get(pte)) | _PAGE_PRESENT)); + mark_new_valid_map(); + } preempt_disable(); local_flush_tlb_kernel_range(addr, addr + PAGE_SIZE); diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 9b9dec6893b8..e7bd03a9ced5 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -107,8 +107,10 @@ SYM_CODE_START(handle_exception) #ifdef CONFIG_64BIT /* - * The RISC-V kernel does not eagerly emit a sfence.vma after each - * new vmalloc mapping, which may result in exceptions: + * The RISC-V kernel does not flush TLBs on all CPUS after each new + * vmalloc mapping or kfence_unprotect(), which may result in + * exceptions: + * * - if the uarch caches invalid entries, the new mapping would not be * observed by the page table walker and an invalidation is needed. * - if the uarch does not cache invalid entries, a reordered access |