On Tue, Oct 17, 2023 at 9:40 PM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote: > > The idea came from the bug I was fixing recently, > 'KASAN: slab-use-after-free Read in tls_encrypt_done'. > > This bug is caused by subtle race condition, where the data structure > is freed early on another CPU, resulting in use-after-free. > > Like this bug, some of the use-after-free bugs are caused by race > condition, but it is not easy to quickly conclude that the cause of the > use-after-free is race condition if only looking at the stack trace. > > I did not think this use-after-free was caused by race condition at the > beginning, it took me some time to read the source code carefully and > think about it to determine that it was caused by race condition. > > By adding timestamps for Allocation, Free, and Error to the KASAN > report, it will be much easier to determine if use-after-free is > caused by race condition. An alternative would be to add the CPU number to the alloc/free stack traces. Something like: Allocated by task 42 on CPU 2: (stack trace) The bad access stack trace already prints the CPU number.
