| Message ID | 1c8ce43f97300300e62c941181afa2eb738965c5.1646237226.git.andreyknvl@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kasan: report clean-ups and improvements | expand |
On Wed, Mar 2, 2022 at 5:37 PM <andrey.konovalov@linux.dev> wrote: > From: Andrey Konovalov <andreyknvl@google.com> > > Currently, end_report() does not call trace_error_report_end() for bugs > detected in either async or asymm mode (when kasan_async_fault_possible() > returns true), as the address of the bad access might be unknown. > > However, for asymm mode, the address is known for faults triggered by > read operations. > > Instead of using kasan_async_fault_possible(), simply check that > the addr is not NULL when calling trace_error_report_end(). > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > --- > mm/kasan/report.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index d60ee8b81e2b..2d892ec050be 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -112,7 +112,7 @@ static void start_report(unsigned long *flags) > > static void end_report(unsigned long *flags, unsigned long addr) > { > - if (!kasan_async_fault_possible()) > + if (addr) > trace_error_report_end(ERROR_DETECTOR_KASAN, addr); > What happens in the case of a NULL dereference? Don't we want to trigger the tracepoint as well?
On Wed, Mar 2, 2022 at 6:38 PM Alexander Potapenko <glider@google.com> wrote: > > > > On Wed, Mar 2, 2022 at 5:37 PM <andrey.konovalov@linux.dev> wrote: >> >> From: Andrey Konovalov <andreyknvl@google.com> >> >> Currently, end_report() does not call trace_error_report_end() for bugs >> detected in either async or asymm mode (when kasan_async_fault_possible() >> returns true), as the address of the bad access might be unknown. >> >> However, for asymm mode, the address is known for faults triggered by >> read operations. >> >> Instead of using kasan_async_fault_possible(), simply check that >> the addr is not NULL when calling trace_error_report_end(). >> >> Signed-off-by: Andrey Konovalov <andreyknvl@google.com> >> --- >> mm/kasan/report.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >> index d60ee8b81e2b..2d892ec050be 100644 >> --- a/mm/kasan/report.c >> +++ b/mm/kasan/report.c >> @@ -112,7 +112,7 @@ static void start_report(unsigned long *flags) >> >> static void end_report(unsigned long *flags, unsigned long addr) >> { >> - if (!kasan_async_fault_possible()) >> + if (addr) >> trace_error_report_end(ERROR_DETECTOR_KASAN, addr); > > > What happens in the case of a NULL dereference? Don't we want to trigger the tracepoint as well? A NULL pointer dereference is never reported through KASAN: for software modes, it triggers a GPF when accessing shadow, and for HW_TAGS, it takes precedence over a tag mismatch. Thanks!
diff --git a/mm/kasan/report.c b/mm/kasan/report.c index d60ee8b81e2b..2d892ec050be 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -112,7 +112,7 @@ static void start_report(unsigned long *flags) static void end_report(unsigned long *flags, unsigned long addr) { - if (!kasan_async_fault_possible()) + if (addr) trace_error_report_end(ERROR_DETECTOR_KASAN, addr); pr_err("==================================================================\n"); add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);