linux-kernel - Re: [PATCH] kasan:fix access invalid shadow address when input is illegal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230914112915.81f55863c0450195b4ed604a@linux-foundation.org>
Date:   Thu, 14 Sep 2023 11:29:15 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Haibo Li <haibo.li@...iatek.com>
Cc:     <linux-kernel@...r.kernel.org>, <xiaoming.yu@...iatek.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        <kasan-dev@...glegroups.com>, <linux-mm@...ck.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH] kasan:fix access invalid shadow address when input is
 illegal

On Thu, 14 Sep 2023 16:08:33 +0800 Haibo Li <haibo.li@...iatek.com> wrote:

> when the input 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 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.
> 
> To fix it,check shadow address by reading it with no fault.
> 
> After this patch,KASAN is able to report invalid memory access
> for this case.
> 

Thanks.

> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -304,8 +304,17 @@ static __always_inline bool addr_has_metadata(const void *addr)
>  #ifdef __HAVE_ARCH_SHADOW_MAP
>  	return (kasan_mem_to_shadow((void *)addr) != NULL);
>  #else
> -	return (kasan_reset_tag(addr) >=
> -		kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
> +	u8 *shadow, shadow_val;
> +
> +	if (kasan_reset_tag(addr) <
> +		kasan_shadow_to_mem((void *)KASAN_SHADOW_START))
> +		return false;
> +	/* use read with nofault to check whether the shadow is accessible */
> +	shadow = kasan_mem_to_shadow((void *)addr);
> +	__get_kernel_nofault(&shadow_val, shadow, u8, fault);
> +	return true;
> +fault:
> +	return false;
>  #endif
>  }

Are we able to identify a Fixes: target for this? 
9d7b7dd946924de43021f57a8bee122ff0744d93 ("kasan: split out
print_report from __kasan_report") altered the code but I expect the
bug was present before that commit.

Seems this bug has been there for over a year.  Can you suggest why it
has been discovered after such a lengthy time?