#endif
> - "+r"(__sp)
> :
> [entry]"r"(entry),
> [ss]"i"(__KERNEL_DS),
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index b836a727
On Tue, Sep 19, 2017 at 2:55 PM, Alexander Potapenko wrote:
> On Tue, Sep 19, 2017 at 11:45 AM, Josh Poimboeuf wrote:
>> For inline asm statements which have a CALL instruction, we list the
>> stack pointer as a constraint to convince GCC to ensure the frame
>> po
Hi Theodore,
Looks like the patch hasn't been landed yet, could you please revisit it?
Thanks,
Alex
On Wed, Jan 18, 2017 at 5:32 PM, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 01:30:15PM +0100, Alexander Potapenko wrote:
>> KMSAN (KernelMemorySanitizer, a new error dete
hat information). Did I mess it up somehow?
Alex
On Wed, May 24, 2017 at 9:32 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 23 May 2017 13:20:28 +0200
>
>> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which led
>> to contents of |ifm| being
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko
---
For the record, here is the KMSAN report
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko
---
v2: fixed an off-by-one error spotted by Dmitry Vyukov
For the record, here
>> R10: c084 R11: 0202 R12:
>> R13: 004025b0 R14: 00402640 R15:
>>
>> On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae
>> .
>>
>
> --
> You received this message because you are subsc
On Wed, May 31, 2017 at 5:10 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Wed, 31 May 2017 10:56:47 +0200
>
>> Hi David,
>>
>> I've noticed that the upstream patch:
>> https://github.com/torvalds/linux/commit/0ff50e83b5122e836ca492fefb11656
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko
---
v3: removed the multi-line comment
v2: fixed an off-by-one error spotted by
On Thu, Jun 1, 2017 at 3:47 PM, Yury Norov wrote:
> On Thu, Jun 01, 2017 at 02:38:29PM +0200, Alexander Potapenko wrote:
>> KMSAN reported a use of uninitialized memory in dev_set_alias(),
>> which was caused by calling strlcpy() (which in turn called strlen())
>> on
On Thu, Jun 1, 2017 at 4:04 PM, Yury Norov wrote:
> On Thu, Jun 01, 2017 at 03:50:33PM +0200, Alexander Potapenko wrote:
>> On Thu, Jun 1, 2017 at 3:47 PM, Yury Norov wrote:
>> > On Thu, Jun 01, 2017 at 02:38:29PM +0200, Alexander Potapenko wrote:
>> >> KMSAN r
ected with KMSAN and syzkaller.
Signed-off-by: Alexander Potapenko
---
For the record, the following program:
===
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_memfd_create
#define __NR_memfd_create 319
#endif
#in
k to the userspace directly.
The bug has been detected with KMSAN and syzkaller.
Signed-off-by: Alexander Potapenko
---
For the record, here is the KMSAN report:
==
BUG: KMSAN: use of unitialized memory in rtnl_fdb_dump+0x5dc/0x100
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko
---
v4: dropped the comment at all, as suggested by Yury Norov
v3: removed the
On Tue, Jun 6, 2017 at 10:36 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Tue, 6 Jun 2017 15:56:54 +0200
>
>> KMSAN reported a use of uninitialized memory in dev_set_alias(),
>> which was caused by calling strlcpy() (which in turn called strlen())
>&g
raw_send_hdrinc() and rawv6_send_hdrinc() expect that the buffer copied
from the userspace contains the IPv4/IPv6 header, so if too few bytes are
copied, parts of the header may remain uninitialized.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko
---
The previous
From: Victor Chibotaru
The flag enables Clang instrumentation of comparison operations
(currently not supported by GCC). This instrumentation is needed by the
new KCOV device to collect comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
From: Victor Chibotaru
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey
On Mon, Oct 9, 2017 at 8:53 AM, Andrey Ryabinin wrote:
>
>
> On 10/09/2017 06:05 PM, Alexander Potapenko wrote:
>
>> v2: - updated KCOV_ENABLE_COMPARISONS description
>> ---
>> Makefile | 5 +++--
>> lib/Kconfig.debug| 10 ++
>&g
On Mon, Oct 9, 2017 at 8:46 AM, Mark Rutland wrote:
> Hi,
>
> I look forward to using this! :)
>
> I just have afew comments below.
>
> On Mon, Oct 09, 2017 at 05:05:19PM +0200, Alexander Potapenko wrote:
>> +/*
>> + * Defines the format for the types of collec
ument value.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey Ryabinin
Cc: Kees Cook
Cc: Vegard Nossum
Cc: Quentin Casasnovas
Cc: syzkal...@googlegroups.com
Cc:
ument value.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey Ryabinin
Cc: Kees Cook
Cc: Vegard Nossum
Cc: Quentin Casasnovas
Cc: syzkal...@googlegroups.com
Cc:
From: Victor Chibotaru
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey
From: Victor Chibotaru
The flag enables Clang instrumentation of comparison operations
(currently not supported by GCC). This instrumentation is needed by the
new KCOV device to collect comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
On Tue, Oct 10, 2017 at 5:34 PM, 'Dmitry Vyukov' via syzkaller
wrote:
> On Tue, Oct 10, 2017 at 5:28 PM, 'Alexander Potapenko' via syzkaller
> wrote:
>> On Mon, Oct 9, 2017 at 8:46 AM, Mark Rutland wrote:
>>> Hi,
>>>
>>> I look forwar
On Tue, Oct 10, 2017 at 5:51 PM, Andrey Ryabinin
wrote:
>
>
> On 10/10/2017 06:27 PM, Alexander Potapenko wrote:
>>
>> v3: - Andrey Ryabinin's comments: reinstated scripts/Makefile.kcov
>> and moved CFLAGS_KCOV there, dropped CFLAGS_KCOV_COMPS
>
> Huh?
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
On Tue, Sep 26, 2017 at 5:02 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Tue, Sep 26, 2017 at 7:53 AM, Alexander Potapenko
> wrote:
>> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
>> skb->data[0] in the case the s
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
; case IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >> 4) : 0;
>
> And na
On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
>>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>>
memset(&req, 0, sizeof(struct ifreq));
strcpy((char*)&req.ifr_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, &req);
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
ument value.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey Ryabinin
Cc: Kees Cook
Cc: Vegard Nossum
Cc: Quentin Casasnovas
Cc: syzkal...@googlegroups.com
Cc:
From: Victor Chibotaru
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: Andrey Konovalov
Cc: Andrew Morton
Cc: Mark Rutland
Cc: Alexander Popov
Cc: Andrey
From: Victor Chibotaru
The flag enables Clang instrumentation of comparison operations
(currently not supported by GCC). This instrumentation is needed by the
new KCOV device to collect comparison operands.
Signed-off-by: Victor Chibotaru
Signed-off-by: Alexander Potapenko
Cc: Dmitry Vyukov
_report(), where
info is allocated?
> if ((unsigned long)info->access_addr < PAGE_SIZE)
> bug_type = "null-ptr-deref";
> else if ((unsigned long)info->access_addr < TASK_SIZE)
> --
> 2.9.0
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
On Wed, Jul 19, 2017 at 2:58 AM, Xin Long wrote:
> On Wed, Jul 19, 2017 at 3:02 AM, Alexander Potapenko
> wrote:
>> On Tue, Jul 18, 2017 at 4:55 PM, Alexander Potapenko
>> wrote:
>>> KMSAN reported use of uninitialized sctp_addr->v4.sin_addr.s_addr and
>
.c:292
==
Signed-off-by: Alexander Potapenko
Reviewed-by: Xin Long
---
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
On Tue, Aug 8, 2017 at 8:47 PM, Marcelo Ricardo Leitner
wrote:
> On Tue, Jul 18, 2017 at 04:55:57PM +0200, Alexander Potapenko wrote:
>> KMSAN reported use of uninitialized sctp_addr->v4.sin_addr.s_addr and
>> sctp_addr->v6.sin6_scope_id in sctp_v6_cmp_addr() (see below).
&g
stackdepot used to call memcmp(), which compiler tools normally
instrument, therefore every lookup used to unnecessarily call
instrumented code.
This is somewhat ok in the case of KASAN, but under KMSAN a lot of time
was spent in the instrumentation.
Signed-off-by: Alexander Potapenko
---
v2: As
$(call cc-param,asan-globals=1) \
> + $(call
> cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> + $(call cc-param,asan-stack=1) \
> + $(call cc-param,asan-use-after-scope=1)
> + endif
> +
> endif
>
> CFLAGS_KASAN += $(c
Commit-ID: 187e91fe5e915f4b7f39b824aa422493463e443d
Gitweb: http://git.kernel.org/tip/187e91fe5e915f4b7f39b824aa422493463e443d
Author: Alexander Potapenko
AuthorDate: Wed, 16 Aug 2017 21:08:08 +0200
Committer: Ingo Molnar
CommitDate: Thu, 17 Aug 2017 09:53:00 +0200
x86/boot/64/clang
Commit-ID: 4a09f0210c8b1221aae8afda8bd3a603fece0986
Gitweb: https://git.kernel.org/tip/4a09f0210c8b1221aae8afda8bd3a603fece0986
Author: Alexander Potapenko
AuthorDate: Wed, 9 May 2018 11:18:22 +0200
Committer: Ingo Molnar
CommitDate: Mon, 14 May 2018 11:14:30 +0200
x86/boot/64/clang
Commit-ID: 5b77e95dd7790ff6c8fbf1cd8d0104ebed818a03
Gitweb: https://git.kernel.org/tip/5b77e95dd7790ff6c8fbf1cd8d0104ebed818a03
Author: Alexander Potapenko
AuthorDate: Tue, 2 Apr 2019 13:28:13 +0200
Committer: Ingo Molnar
CommitDate: Sat, 6 Apr 2019 09:52:02 +0200
x86/asm: Use
Commit-ID: 469f00231278da68062a809306df0bac95a27507
Gitweb: http://git.kernel.org/tip/469f00231278da68062a809306df0bac95a27507
Author: Alexander Potapenko
AuthorDate: Fri, 15 Jul 2016 11:42:43 +0200
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:19:33 +0200
x86, kasan, ftrace
601 - 645 of 645 matches
Mail list logo
