> On Mon, 9 Oct 2023 15:37:48 +0800 Haibo Li <haibo.li@xxxxxxxxxxxx> wrote:
>
> > when the checked address is illegal,the corresponding shadow address
> > from kasan_mem_to_shadow may have no mapping in mmu table.
> > Access such shadow address causes kernel oops.
> > Here is a sample about oops on arm64(VA 39bit)
> > with KASAN_SW_TAGS and KASAN_OUTLINE on:
> >
> > [ffffffb80aaaaaaa] pgd=000000005d3ce003, p4d=000000005d3ce003,
> > pud=000000005d3ce003, pmd=0000000000000000
> > Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 3 PID: 100 Comm: sh Not tainted 6.6.0-rc1-dirty #43
> > Hardware name: linux,dummy-virt (DT)
> > pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > pc : __hwasan_load8_noabort+0x5c/0x90
> > lr : do_ib_ob+0xf4/0x110
> > ffffffb80aaaaaaa is the shadow address for efffff80aaaaaaaa.
> > The problem is reading invalid shadow in kasan_check_range.
> >
> > The generic kasan also has similar oops.
> >
> > It only reports the shadow address which causes oops but not
> > the original address.
> >
> > Commit 2f004eea0fc8("x86/kasan: Print original address on #GP")
> > introduce to kasan_non_canonical_hook but limit it to KASAN_INLINE.
> >
> > This patch extends it to KASAN_OUTLINE mode.
>
> Is 2f004eea0fc8 a suitable Fixes: target for this? If not, what is?
>
Yes, 2f004eea0fc8 is a suitable fix.
All we need is a better crash report for this case.
After commit 2f004eea0fc8 and commit
07b742a4d912 ("arm64: mm: log potential KASAN shadow alias"),
it is easy to understand the original address when
out-of-bounds KASAN shadow accesses occur.
Currently, this feature is only available for the KASAN_INLINE case.
As Jann said, it is also suitable for the KASAN_OUTLINE case.
> Also, I'm assuming that we want to backport this fix into earlier
> kernel versions?
My opinion:
As it is to improve crash report,there is no requirement to backport.
