diff options
| author | Vivian Wang <wangruikang@iscas.ac.cn> | 2026-03-03 08:29:46 +0300 |
|---|---|---|
| committer | Paul Walmsley <pjw@kernel.org> | 2026-06-07 08:48:15 +0300 |
| commit | 8d6c8c40e733b3fcaf92fed0a078bba2f6941a3b (patch) | |
| tree | a8fb53efb9d9d95a7225c0d2ef2f6b45394f9fc7 /include/linux/debugobjects.h | |
| parent | 9ee25d0a70ff4494b4e1d266b962d0a574ef318a (diff) | |
| download | linux-8d6c8c40e733b3fcaf92fed0a078bba2f6941a3b.tar.xz | |
riscv: kfence: Call mark_new_valid_map() for kfence_unprotect()
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>
Diffstat (limited to 'include/linux/debugobjects.h')
0 files changed, 0 insertions, 0 deletions
