Thread (51 messages) 51 messages, 3 authors, 2024-06-20

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

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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help