e.org/gmane.linux.kernel/2266971 in the discussion,
and my patch seems to have fixed the problem.
Adding __GFP_NOWARN will mask further problems of the similar nature,
so I think we'd better avoid it.
>> use __GFP_NOWARN for stack
>>
>> Link: http://lkml.kernel.org/r/2016072
On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann wrote:
> Hi
>
> On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov wrote:
>> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko
>> wrote:
>>> Hello,
>>>
>>> the program below tr
On Sun, Jun 19, 2016 at 7:40 PM, Sasha Levin wrote:
> On 06/19/2016 03:24 AM, Alexander Potapenko wrote:
>> Hi Sasha,
>>
>> This commit delays the reuse of memory after it has been freed, so
>> it's intended to help people find more use-after-free errors.
>
ct).
> Hopefully the occupied memory doesn't grow indefinitely over time then...
The existing use case (allocation/deallocation stacks for KASAN
reports) doesn't require reference counts. Introducing those would
have added unwanted contention and increase memory usage.
The amount of
On Sun, Jun 19, 2016 at 7:40 PM, Sasha Levin wrote:
> On 06/19/2016 03:24 AM, Alexander Potapenko wrote:
>> Hi Sasha,
>>
>> This commit delays the reuse of memory after it has been freed, so
>> it's intended to help people find more use-after-free errors.
>
On Mon, Jun 20, 2016 at 9:50 PM, Sasha Levin wrote:
> On 06/20/2016 08:53 AM, Alexander Potapenko wrote:
>> On Sun, Jun 19, 2016 at 7:40 PM, Sasha Levin wrote:
>>> > On 06/19/2016 03:24 AM, Alexander Potapenko wrote:
>>>> >> Hi Sasha,
>>>> >
t other uses of llist_entry()
to llist_entry_safe(), or even replace uses of container_of() with
container_of_safe().
Alexander Potapenko (2):
include/linux: provide a safe version of container_of()
llist: introduce llist_entry_safe()
include/linux/kernel.h | 15 +++
include/linu
nd the
loops become infinite.
To work around this, introduce llist_entry_safe(), which returns NULL
for NULL pointers, and additionally check that pos is not NULL in the
list iterators before dereferencing it.
Signed-off-by: Alexander Potapenko
---
include/linux/llist.h | 26 +++
case
the member offset within the container is greater than the pointer to
the member, otherwise it returns the result of container_of().
Signed-off-by: Alexander Potapenko
---
Note that checkpatch.pl reports whitespace problems in this patch, but
the diff is consistent with the rest of the fil
There's no point in collecting coverage from lib/stackdepot.c, as it is
not a function of syscall inputs. Disabling kcov instrumentation for
that file will reduce the coverage noise level.
Signed-off-by: Alexander Potapenko
---
lib/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --
-m 320 -smp 1 -device
> e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog
> i6300esb -rtc base=localtime -drive
> file=/fs/sdg1/disk0-vm-kbuild-yocto-x86_64-59,media=disk,if=virtio -pidfile
> /dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-59 -serial
> file
When free_meta_offset is not zero, it is usually aligned on 4 bytes,
because the size of preceding kasan_alloc_meta is aligned on 4 bytes.
As a result, accesses to kasan_free_meta fields may be misaligned.
Signed-off-by: Alexander Potapenko
---
mm/kasan/kasan.c | 3 ++-
1 file changed, 2
led to random stacks having been reported.
Fixes: 7ed2f9e663854db ("mm, kasan: SLAB support")
Signed-off-by: Alexander Potapenko
---
v8: - Updated the patch description
---
include/linux/slub_def.h | 10 ++
mm/slub.c| 2 +-
2 files changed, 7 insertions(+), 5
For KASAN builds:
- switch SLUB allocator to using stackdepot instead of storing the
allocation/deallocation stacks in the objects;
- change the freelist hook so that parts of the freelist can be put
into the quarantine.
Signed-off-by: Alexander Potapenko
---
v8: - incorporated fixes by
This patch set enables stackdepot and quarantine for SLUB allocator and
fixes a problem with incorrect calculating the offset of the nearest
object in the presence of SLUB red zones.
Alexander Potapenko (3):
mm, kasan: account for object redzone in SLUB's nearest_obj()
mm, kasan:
Sent patchset v8 to fix this problem.
On Wed, Jul 27, 2016 at 3:30 PM, Alexander Potapenko wrote:
> I couldn't reproduce the problem locally. But most likely this happens
> because kasan_create_cache() sometimes sets
> cache->kasan_info.free_meta_offset to a multiple of 4.
>
0
> [] SyS_clone+0x19/0x20
> [] do_syscall_64+0x1a0/0x4e0
> [] entry_SYSCALL64_slow_path+0x25/0x25
>
> Fix this by putting an object in the quarantine after all other operations.
>
> Fixes: 80a9201a5965 ("mm, kasan: switch SLUB to stackdepot, enable memory
> quar
On Mon, Aug 1, 2016 at 4:45 PM, Andrey Ryabinin wrote:
> SLUB doesn't require disabled interrupts to call ___cache_free().
>
> Signed-off-by: Andrey Ryabinin
Acked-by: Alexander Potapenko
> ---
> mm/kasan/quarantine.c | 8 ++--
> 1 file changed, 6 insertions(+),
On Mon, Aug 1, 2016 at 4:55 PM, Andrey Ryabinin wrote:
>
>
> On 07/28/2016 06:31 PM, Alexander Potapenko wrote:
>> When free_meta_offset is not zero, it is usually aligned on 4 bytes,
>> because the size of preceding kasan_alloc_meta is aligned on 4 bytes.
>&g
Signed-off-by: Alexander Potapenko
---
mm/kasan/quarantine.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 65793f1..416d3b0 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -196,7 +196
On Mon, Aug 1, 2016 at 5:11 PM, Andrey Ryabinin wrote:
>
>
> On 08/01/2016 05:56 PM, Alexander Potapenko wrote:
>> On Mon, Aug 1, 2016 at 4:55 PM, Andrey Ryabinin
>> wrote:
>>>
>>>
>>> On 07/28/2016 06:31 PM, Alexander Potapenko wrote:
>&
On Wed, Aug 24, 2016 at 8:19 PM, Levin, Alexander
wrote:
> On Wed, Aug 24, 2016 at 12:37:35PM -0400, Alexander Potapenko wrote:
>> he script that symbolizes BUG messages and KASAN error reports
>> by adding file:line information to each stack frame.
>> The script
On Fri, Jul 15, 2016 at 11:42 AM, Alexander Potapenko wrote:
> When building with CONFIG_FUNCTION_GRAPH_TRACER or CONFIG_KASAN, put the
> APIC interrupt handlers into the .irqentry.text section. This is needed
> because both KASAN and function graph tracer use __irqentry_text_
Ryabinin
Cc: Dmitry Vyukov
Signed-off-by: Alexander Potapenko
---
MAINTAINERS | 1 +
scripts/ksymbolize.py | 320 ++
2 files changed, 321 insertions(+)
create mode 100755 scripts/ksymbolize.py
diff --git a/MAINTAINERS b/MAINTAINERS
index
.c:292
==
Signed-off-by: Alexander Potapenko
Reviewed-by: Xin Long
Acked-by: Marcelo Ricardo Leitner
---
v3: set flowinfo between port and addr to ease code review.
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2
ted a R_X86_64_32S, which led to
accessing invalid memory and rebooting the kernel.
Cc: Kirill A. Shutemov
Cc: Dmitry Vyukov
Cc: Michael Davidson
Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C")
Signed-off-by: Alexander Potapenko
---
arch/x86/kernel/head64.c | 7 ---
1
On Wed, Aug 16, 2017 at 9:08 PM, Alexander Potapenko wrote:
> __startup_64() is normally using fixup_pointer() to access globals in a
> position-independent fashion. However |next_early_pgt| was accessed
> directly, which wasn't guaranteed to work.
>
> Luckily GCC was genera
; > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> >
> --
> Jan Kara
> SUSE Labs, CR
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20180829134620.GD7369%40quack2.suse.cz.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
v2: fixed a typo spotted
preferred_node, however, __mpol_equeue() use
> preferred_node without check whether it is MPOL_F_LOCAL or not.
>
> Reported-by: Alexander Potapenko
> Signed-off-by: Yisheng Xie
Tested-by: Alexander Potapenko
I confirm that the patch fixes the problem. Thanks for the quick turnaround
KMSAN reports use of uninitialized memory in the case when |alen| is
smaller than sizeof(struct netlink_sock), and therefore |nladdr| isn't
fully copied from the userspace.
Signed-off-by: Alexander Potapenko
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
---
net/netlink/af_netli
stack data.
Signed-off-by: Alexander Potapenko
Reported-by: syzbot+69c3bd9869b32e394...@syzkaller.appspotmail.com
Fixes: 84c751bd4aebb ("ptrace: add ability to retrieve signals without
removing from a queue (v4)")
Cc: Andrey Vagin
Cc: Oleg Nesterov
Cc: Willy Tarreau
---
kernel/ptrace.
On Thu, Nov 15, 2018 at 5:05 AM Kyungtae Kim wrote:
>
> Thank you for all your comments.
>
> Thanks,
> Kyungtae Kim
> On Wed, Nov 14, 2018 at 11:05 AM Paul E. McKenney
> wrote:
> >
> > On Wed, Nov 14, 2018 at 04:31:11PM +0100, Alexander Potapenko wrote:
>
> avc_alloc_node+0x109/0xb90 security/selinux/avc.c:572
> > avc_insert security/selinux/avc.c:696 [inline]
> > avc_compute_av+0x31e/0x1050 security/selinux/avc.c:1008
> > avc_has_perm_noaudit+0x516/0x770 security/selinux/avc.c:1149
> > avc_has_perm+0x172/0x480 securi
ug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bug
On Fri, Nov 9, 2018 at 12:18 PM Takashi Iwai wrote:
>
> On Fri, 09 Nov 2018 10:31:03 +0100,
> Alexander Potapenko wrote:
> >
> > On Thu, Nov 8, 2018 at 9:38 PM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the fol
the problem
Reported-by: syzbot+17a8efdf800...@syzkaller.appspotmail.com
Signed-off-by: Alexander Potapenko
---
drivers/tty/vt/vt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1eb1a376a041..15eb6c829d39 100644
--- a
On Wed, May 16, 2018 at 6:45 PM Andrey Ryabinin
wrote:
> On 05/16/2018 06:34 PM, Alexander Potapenko wrote:
> > stackdepot used to call memcpy(), which compiler tools normally
> > instrument, therefore every lookup used to unnecessarily call
instrumented
> > code. This
This shall help avoid copying uninitialized memory to the userspace
when calling ioctl(fd, SG_IO) with an empty command.
Reported-by: syzbot+7d26fc1eea198488d...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Alexander Potapenko
Acked-by: Douglas Gilbert
Reviewed-by
On Thu, Sep 13, 2018 at 11:23 AM Alexander Potapenko wrote:
>
> On Thu, Sep 13, 2018 at 11:18 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:123906095e30 kmsan: introduce kmsan_interrupt_enter()/
ead(const volatile void *p, unsigned int size);
> > void kasan_check_write(const volatile void *p, unsigned int size);
> > #else
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 03d5d1374ca7..51a7932c33a3 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasa
stead of the inline function.
> > >
> > > Fixes: b1864b828644 ("locking/atomics: build atomic headers as required")
> > > Reported-by: Anders Roxell
> > > Signed-off-by: Arnd Bergmann
Reviewed-by: Alexander Potapenko
> > > ---
> &g
On Wed, Dec 19, 2018 at 2:23 PM Jens Axboe wrote:
>
> On 12/19/18 3:23 AM, Alexander Potapenko wrote:
> > On Thu, Sep 13, 2018 at 11:23 AM Alexander Potapenko
> > wrote:
> >>
> >> On Thu, Sep 13, 2018 at 11:18 AM syzbot
> >> wrote:
> >>
ask)
> > {
> > if (!pol)
> > return;
> > - if (!mpol_store_user_nodemask(pol) &&
> > + if (!mpol_store_user_nodemask(pol) && !(pol->flags & MPOL_F_LOCAL)
> > &&
> > nodes_equal(po
testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view
contains any reasonable data regardless of actual
address length.
I suspect the bug has been introduced in
https://github.com/torvalds/linux/commit/0f8db8cc73df60b3de9a5eebd8f117b56eff5b03
>
> Thanks,
> Kyungtae Kim
>
> --
> You received this message because you are subscribed
variable. Disable instrumentation in the respective functions. They are
> very small and it's easy to see that no important metadata updates are
> lost because of this.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
memory() calls for the output buffers.
> The logic is the same as in [1].
>
> [1]
> https://github.com/zlib-ng/zlib-ng/commit/1f5ddcc009ac3511e99fc88736a9e1a6381168c5
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
>
On Thu, Jan 4, 2024 at 9:45 PM Stefan Hajnoczi wrote:
>
> On Tue, Jan 02, 2024 at 08:03:46AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 01, 2024 at 05:38:24AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:fbafc3e621c3 Merge tag
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Hi,
>
> This series provides the minimal support for Kernel Memory Sanitizer on
> s390. Kernel Memory Sanitizer is clang-only instrumentation for finding
> accesses to uninitialized memory. The clang support for s390 has already
> been me
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> Like for KASAN, it's useful to temporarily disable KMSAN checks around,
> e.g., redzone accesses.
This example is incorrect, because KMSAN does not have redzones.
You are calling these functions from "mm: slub: Let KMSAN access
metadata"
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> The unwind code can read uninitialized frames. Furthermore, even in
> the good case, KMSAN does not emit shadow for backchains. Therefore
> disable it for the unwinding functions.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/ke
On Thu, Nov 16, 2023 at 10:04 AM Alexander Potapenko wrote:
>
> On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
> >
> > The unwind code can read uninitialized frames. Furthermore, even in
> > the good case, KMSAN does not emit shadow for backchains. Therefor
to improve the KMSAN usability for
> modules.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich wrote:
>
> All other sanitizers are disabled for these components as well.
>
> Reviewed-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see a nit below)
> ---
> arch/s390/boot/
sting.
Nice!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
KMSAN for now.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
stens
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see the comment below)
>
> -#include
> +#include
For the sake of consistency with other KMSAN code, please keep the
headers sorted alphabetically.
viewed-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
ts.
Good catch, thank you!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
shkevich
Reviewed-by: Alexander Potapenko
nfig option to describe this situation, so explicitly check for
> s390.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(see the nit below)
> ---
> mm/kmsan/init.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kmsan/init.c
ata for page operations")
> Suggested-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> ---
> mm/kmsan/shadow.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/kmsan/shadow.c b/mm/kmsan/shadow.c
> index b9d05aff313e..2
On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich 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.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> mm/kmsan/hooks.c | 2
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> The pages for the KMSAN metadata associated with most kernel mappings
> are taken from memblock by the common code. However, vmalloc and module
> metadata needs to be defined by the architectures.
>
> Be a little bit more careful than x86
On Wed, Nov 15, 2023 at 9:35 PM Ilya Leoshkevich wrote:
>
> This is normally done by the generic entry code, but the
> kernel_stack_overflow() flow bypasses it.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> ---
> arch/s390/kernel/traps.c | 2 ++
Hi Ilya,
Sorry for this taking so long, I'll probably take a closer look next week.
Overall, the s390 part looks good to me, but I wanted to check the x86
behavior once again (and perhaps figure out how to avoid introducing
another way to disable KMSAN).
Do you happen to have a Git repo with your
ds.
>
> Unpoisoning the canary is not the right thing to do: only
> check_canary() is supposed to ever touch it. Instead, disable KMSAN
> checks around canary read accesses.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> The constraints of the DFLTCC inline assembly are not precise: they
> do not communicate the size of the output buffers to the compiler, so
> it cannot automatically instrument it.
KMSAN usually does a poor job instrumenting inline asse
-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:06 PM Ilya Leoshkevich wrote:
>
> Add a wrapper for memset() that prevents unpoisoning.
We have __memset() already, won't it work for this case?
On the other hand, I am not sure you want to preserve the redzone in
its previous state (unless it's known to be poisoned).
Y
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich 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. The usage of
> memset_no_sanitize_memory() does not degrade the g
On Fri, Dec 8, 2023 at 1:53 PM Alexander Potapenko wrote:
>
> On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
> >
> > KMSAN warns about check_canary() accessing the canary.
> >
> > The reason is that, even though set_canary() is properly instrumented
> &
arnings when running the ftrace testsuite.
I couldn't reproduce these warnings on x86, hope you really need this
change on s390 :)
> Fix by trusting the architecture-specific assembly code and always
> unpoisoning ftrace_regs in ftrace_ops_list_func.
>
> Signed-off-by: Ily
ngs when running the ftrace testsuite.
>
> Fix by trusting the assembly code and always unpoisoning ftrace_regs in
> kprobe_ftrace_handler().
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Fri, Dec 8, 2023 at 3:14 PM Ilya Leoshkevich wrote:
>
> On Fri, 2023-12-08 at 14:32 +0100, Alexander Potapenko wrote:
> > On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich
> > wrote:
> > >
> > > The constraints of the DFLTCC inline assembly are not precis
> A problem with __memset() is that, at least for me, it always ends
> up being a call. There is a use case where we need to write only 1
> byte, so I thought that introducing a call there (when compiling
> without KMSAN) would be unacceptable.
Wonder what happens with that use case if we e.g. bui
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> The inline assembly block in s390's chsc() stores that much.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Currently KMSAN does not fully propagate metadata in strlcpy() and
> strlcat(), because they are built with -ffreestanding and call
> memcpy(). In this combination memcpy() calls are not instrumented.
Is this something specific to s390?
On Tue, Nov 21, 2023 at 11:07 PM Ilya Leoshkevich wrote:
>
> It is useful to manually copy metadata in order to describe the effects
> of memmove()-like logic in uninstrumented code or inline asm. Introduce
> kmsan_memmove_metadata() for this purpose.
>
> Signed-off-by: Ilya Leoshkevich
> ---
>
an_unpoison_memory()
> definition. This produces some runtime overhead, but only when building
> with CONFIG_KMSAN. The benefit is that it does not disturb the existing
> KMSAN build logic and call sites don't need to be changed.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Comparing pointers with TASK_SIZE does not make sense when kernel and
> userspace overlap. Skip the comparison when this is the case.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
> +static inline void *kmsan_get_metadata(void *addr, bool is_origin)
> +{
> + return NULL;
> +}
> +
> #endif
We shouldn't need this part, as kmsan_get_metadata() should never be
called in non-KMSAN builds.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
(hope some s390 maintainer acks this as well)
> +static inline void *arch_kmsan_get_meta_or_null(void *addr, bool is_origin)
> +{
> + if (addr >= (void *)&S390_lowcore &&
> + addr < (void *)(&S390_lowcore + 1)) {
> + /*
> +* Different lowcores accessed via S390_lowcore are described
> +
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich wrote:
>
> Prevent KMSAN from complaining about buffers filled by cpacf_trng()
> being uninitialized.
>
> Tested-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
lloc_low().
> But since this question came up, I should probably add a check and
> a WARN_ON_ONCE() here.
Yes, please.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -numme
On Tue, Nov 21, 2023 at 11:03 PM Ilya Leoshkevich wrote:
>
> put_user() uses inline assembly with precise constraints, so Clang is
> in principle capable of instrumenting it automatically. Unfortunately,
> one of the constraints contains a dereferenced user pointer, and Clang
> does not currently
64() definitions, depending on whether the code is built with
> sanitizers or fortify. This should probably be streamlined, but in the
> meantime resolve the issues by introducing the IN_BOOT_STRING_C macro,
> similar to the existing IN_ARCH_STRING_C macro.
>
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Nov 21, 2023 at 11:06 PM Ilya Leoshkevich wrote:
>
> Like for KASAN, it's useful to temporarily disable KMSAN checks around,
> e.g., redzone accesses. Introduce kmsan_disable_current() and
> kmsan_enable_current(), which are similar to their KASAN counterparts.
Initially we used to have t
the whole dest manually with kmsan_unpoison_memory().
>
> Reported-by: Alexander Gordeev
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
shkevich
Reviewed-by: Alexander Potapenko
On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich wrote:
>
> put_user() uses inline assembly with precise constraints, so Clang is
> in principle capable of instrumenting it automatically. Unfortunately,
> one of the constraints contains a dereferenced user pointer, and Clang
> does not currently d
inter. While at it, prettify them too.
>
> Suggested-by: Heiko Carstens
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Tue, Jun 18, 2024 at 11:40 AM Ilya Leoshkevich wrote:
>
> On Tue, 2024-06-18 at 11:24 +0200, Alexander Potapenko wrote:
> > On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich
> > wrote:
> > >
> > > put_user() uses inline assembly with precise constraints,
n, where possible.
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
isable() functions to KMSAN.
>
> Acked-by: Vlastimil Babka
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
ble memory, in turn
> causing virt_to_page_or_null() in kmsan_init_alloc_meta_for_range() to
> return NULL, which leads to kernel panic shortly after.
>
> Since the padding bytes are not used, drop the rounding.
Nice catch, thanks!
> Signed-off-by: Ilya Leoshkevich
Reviewed-by: Alexander Potapenko
On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich wrote:
>
> Even though the KMSAN warnings generated by memchr_inv() are suppressed
> by metadata_access_enable(), its return value may still be poisoned.
>
> The reason is that the last iteration of memchr_inv() returns
> `*start != value ? start :
On Fri, Jun 14, 2024 at 1:44 AM Ilya Leoshkevich wrote:
>
> On Thu, 2024-06-13 at 16:30 -0700, SeongJae Park wrote:
> > Hi Ilya,
> >
> > On Thu, 13 Jun 2024 17:34:14 +0200 Ilya Leoshkevich
> > wrote:
> >
> > > Avoid false KMSAN negatives with SLUB_DEBUG by allowing
> > > kmsan_slab_free() to pois
1 - 100 of 645 matches
Mail list logo
