From: Juntong Deng <juntong.deng@outlook.com>
To: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
dvyukov@google.com, vincenzo.frascino@arm.com,
akpm@linux-foundation.org
Cc: kasan-dev@googlegroups.com, linux-mm@kvack.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kernel-mentees@lists.linuxfoundation.org"
<linux-kernel-mentees@lists.linuxfoundation.org>
Subject: [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN report
Date: Wed, 18 Oct 2023 03:39:59 +0800 [thread overview]
Message-ID: <VI1P193MB075256E076A09E5B2EF7A16F99D6A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM> (raw)
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
next reply other threads:[~2023-10-17 19:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 19:39 Juntong Deng [this message]
2023-10-17 20:10 ` Ricardo B. Marliere
2023-10-25 19:22 ` Andrey Konovalov
2023-10-29 9:05 ` Juntong Deng
2023-10-30 6:29 ` Dmitry Vyukov
2023-10-30 9:28 ` Juntong Deng
2023-10-30 10:10 ` Dmitry Vyukov
2023-10-30 11:32 ` Juntong Deng
2023-10-31 9:46 ` Dmitry Vyukov
2023-11-02 14:58 ` Andrey Konovalov
2023-11-09 19:40 ` Juntong Deng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1P193MB075256E076A09E5B2EF7A16F99D6A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM \
--to=juntong.deng@outlook.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryabinin.a.a@gmail.com \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox