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. If the free time is slightly before the error time, then there is a high probability that this is an error caused by race condition. If the free time is long before the error time, then this is obviously not caused by race condition, but by something else. In addition, I read the source code of KASAN, and it is not a difficult task to add the function of recording timestamps, which can be done by adding a member to struct kasan_track. If it is a good idea, I can do this part of the work. Welcome to discuss! Juntong Deng
