linux-kernel - Re: [PATCH 5/9] XArray: entry in last level is not expected to be a node

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: <20200405215636.GW21484@bombadil.infradead.org>
Date:   Sun, 5 Apr 2020 14:56:36 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Wei Yang <richard.weiyang@...il.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] XArray: entry in last level is not expected to be a
 node

On Sun, Apr 05, 2020 at 11:07:43AM +0000, Wei Yang wrote:
> Occasionally, I see this error message without my change on 5.6.

I've never seen this one before.  Maybe my test machine is insufficient ...

> random seed 1586068185
> running tests
> XArray: 21151201 of 21151201 tests passed
> =================================================================
> ==6040==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0031bce81 at pc 0x00000040b4b3 bp 0x7f95e87f9bb0 sp 0x7f95e87f9ba0
> READ of size 1 at 0x60c0031bce81 thread T11
>     #0 0x40b4b2 in xas_find_marked ../../../lib/xarray.c:1182
>     #1 0x45318e in tagged_iteration_fn /root/git/linux/tools/testing/radix-tree/iteration_check.c:77
>     #2 0x7f95ef2464e1 in start_thread (/lib64/libpthread.so.0+0x94e1)
>     #3 0x7f95ee8026d2 in clone (/lib64/libc.so.6+0x1016d2)
> 
> 0x60c0031bce81 is located 1 bytes inside of 128-byte region [0x60c0031bce80,0x60c0031bcf00)
> freed by thread T1 here:
>     #0 0x7f95ef36c91f in __interceptor_free (/lib64/libasan.so.5+0x10d91f)
>     #1 0x43e4ba in kmem_cache_free /root/git/linux/tools/testing/radix-tree/linux.c:64
> 
> previously allocated by thread T13 here:
>     #0 0x7f95ef36cd18 in __interceptor_malloc (/lib64/libasan.so.5+0x10dd18)
>     #1 0x43e1af in kmem_cache_alloc /root/git/linux/tools/testing/radix-tree/linux.c:44
> 
> Thread T11 created by T0 here:
>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>     #1 0x454862 in iteration_test /root/git/linux/tools/testing/radix-tree/iteration_check.c:178
> 
> Thread T1 created by T0 here:
>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>     #1 0x7f95ef235b89  (/lib64/liburcu.so.6+0x3b89)
> 
> Thread T13 created by T0 here:
>     #0 0x7f95ef299955 in pthread_create (/lib64/libasan.so.5+0x3a955)
>     #1 0x4548a4 in iteration_test /root/git/linux/tools/testing/radix-tree/iteration_check.c:186
> 
> This is not always like this. Didn't figure out the reason yet. Hope you many
> have some point.

How often are you seeing it?

T1 (the thread which frees the memory) is the RCU thread, so the freeing
went through RCU.  For some reason, T11 (the iterating thread) isn't
preventing the freeing by its use of the RCU read lock.