From 47112d359b36899893a386f572bd1a4ab007e8a2 Mon Sep 17 00:00:00 2001 From: Mark Johnston Date: Sat, 14 Sep 2024 01:32:06 +0000 Subject: [PATCH] kassert: Remove KASAN marking from DEBUG_POISON_POINTER While this approach works for trapping reads of an uninitialized pointer, it means that any attempt to store to the variable triggers a KASAN report, which is not what we want. Simply remove the kasan_mark() call. KMSAN will catch these kinds of bugs automatically anyway. Reported by: syzbot+c5e279db5763b58e8d69@syzkaller.appspotmail.com MFC after: 1 week --- sys/sys/kassert.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sys/sys/kassert.h b/sys/sys/kassert.h index ab2313bcbd8..8dcea8352fd 100644 --- a/sys/sys/kassert.h +++ b/sys/sys/kassert.h @@ -38,8 +38,7 @@ extern const char *panicstr; /* panic message */ #define KERNEL_PANICKED() __predict_false(panicstr != NULL) /* - * Trap accesses going through a pointer. Moreover if kasan is available trap - * reading the pointer itself. + * Trap accesses going through a pointer. * * Sample usage: you have a struct with numerous fields and by API contract * only some of them get populated, even if the implementation temporary writes @@ -61,7 +60,6 @@ extern caddr_t poisoned_buf; #define DEBUG_POISON_POINTER(x) ({ \ x = (void *)(DEBUG_POISON_POINTER_VALUE); \ - kasan_mark(&x, 0, sizeof(x), KASAN_GENERIC_REDZONE); \ }) #else