[PATCH] kasan:fix access invalid shadow address when input is illegal

[Andrey Konovalov]

On Thu, Sep 14, 2023 at 10:41 PM Jann Horn <jannh at google.com> wrote:
>
> > Accessing unmapped memory with KASAN always led to a crash when
> > checking shadow memory. This was reported/discussed before. To improve
> > crash reporting for this case, Jann added kasan_non_canonical_hook and
> > Mark integrated it into arm64. But AFAIU, for some reason, it stopped
> > working.
> >
> > Instead of this patch, we need to figure out why
> > kasan_non_canonical_hook stopped working and fix it.
> >
> > This approach taken by this patch won't work for shadow checks added
> > by compiler instrumentation. It only covers explicitly checked
> > accesses, such as via memcpy, etc.
>
> FWIW, AFAICS kasan_non_canonical_hook() currently only does anything
> under CONFIG_KASAN_INLINE;

Ah, right. I was thinking about the inline mode, but the patch refers
to the issue with the outline mode.

However, I just checked kasan_non_canonical_hook for SW_TAGS with the
inline mode: it does not work when accessing 0x42ffffb80aaaaaaa, the
addr < KASAN_SHADOW_OFFSET check fails. It appears there's something
unusual about how instrumentation calculates the shadow address. I
didn't investigate further yet.

> I think the idea when I added that was that
> it assumes that when KASAN checks an access in out-of-line
> instrumentation or a slowpath, it will do the required checks to avoid
> this kind of fault?

Ah, no, KASAN doesn't do it.

However, I suppose we could add what the original patch proposes for
the outline mode. For the inline mode, it seems to be pointless, as
most access checks happen though the compiler inserted code anyway.

I also wonder how much slowdown this patch will introduce.

Haibo, could you check how much slower the kernel becomes with your
patch? If possible, with all GENERIC/SW_TAGS and INLINE/OUTLINE
combinations.

If the slowdown is large, we can just make kasan_non_canonical_hook
work for both modes (and fix it for SW_TAGS).