Re: [PATCH v5 13/37] kmsan: Support SLAB_POISON
From: Alexander Potapenko <glider@google.com>
Date: 2024-06-20 14:59:19
Also in:
linux-mm, linux-s390, lkml
From: Alexander Potapenko <glider@google.com>
Date: 2024-06-20 14:59:19
Also in:
linux-mm, linux-s390, lkml
On Wed, Jun 19, 2024 at 5:45 PM Ilya Leoshkevich [off-list ref] wrote:
Avoid false KMSAN negatives with SLUB_DEBUG by allowing kmsan_slab_free() to poison the freed memory, and by preventing init_object() from unpoisoning new allocations by using __memset(). There are two alternatives to this approach. First, init_object() can be marked with __no_sanitize_memory. This annotation should be used with great care, because it drops all instrumentation from the function, and any shadow writes will be lost. Even though this is not a concern with the current init_object() implementation, this may change in the future. Second, kmsan_poison_memory() calls may be added after memset() calls. The downside is that init_object() is called from free_debug_processing(), in which case poisoning will erase the distinction between simply uninitialized memory and UAF. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Alexander Potapenko <glider@google.com>