linux-kernel - [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN report

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-next>] [day] [month] [year] [list]

Message-ID: <VI1P193MB075256E076A09E5B2EF7A16F99D6A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
Date:   Wed, 18 Oct 2023 03:39:59 +0800
From:   Juntong Deng <juntong.deng@...look.com>
To:     ryabinin.a.a@...il.com, glider@...gle.com, andreyknvl@...il.com,
        dvyukov@...gle.com, vincenzo.frascino@....com,
        akpm@...ux-foundation.org
Cc:     kasan-dev@...glegroups.com, linux-mm@...ck.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-kernel-mentees@...ts.linuxfoundation.org" 
        <linux-kernel-mentees@...ts.linuxfoundation.org>
Subject: [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN
 report

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