I'm trying to make is "do we need to block this
> patch set until issues with the C standards body in regards to the
> kernels memory model are resolved?" I would hope the two are
> orthogonal and that we'd take them and then test them even more
> extensively than the develo
s to the
> kernels memory model are resolved?" I would hope the two are
> orthogonal and that we'd take them and then test them even more
> extensively than the developer has in order to find out.
>
>> It would be good to get something similar to LKMM into KTSAN, for
>> examp
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 <
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
On Thu, Nov 16, 2017 at 4:08 PM, Andrey Ryabinin
<aryabi...@virtuozzo.com> wrote:
>
>
> On 11/15/2017 08:34 PM, Alexander Potapenko wrote:
>> stackdepot used to call memcmp(), which compiler tools normally
>> instrument, therefore every lookup used to unnecessaril
On Thu, Nov 16, 2017 at 4:08 PM, Andrey Ryabinin
wrote:
>
>
> On 11/15/2017 08:34 PM, Alexander Potapenko wrote:
>> stackdepot used to call memcmp(), which compiler tools normally
>> instrument, therefore every lookup used to unnecessarily call
>> instrumented c
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 <
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
---
lib
> per-protocol handlers run.
>>>>
>>>> Note that leaks like this are mitigated by building with
>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>>>>
>>>> Reported-by: Alexander Potapenko <gli...@google.com>
>>>> Cc: "David
his are mitigated by building with
>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y
>>>>
>>>> Reported-by: Alexander Potapenko
>>>> Cc: "David S. Miller"
>>>> Cc: net...@vger.kernel.org
>>>> Signed-off-by: Kees Cook
>>&
On Tue, Oct 10, 2017 at 5:51 PM, Andrey Ryabinin
<aryabi...@virtuozzo.com> 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 CFL
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? Try a
On Tue, Oct 10, 2017 at 5:34 PM, 'Dmitry Vyukov' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Tue, Oct 10, 2017 at 5:28 PM, 'Alexander Potapenko' via syzkaller
> <syzkal...@googlegroups.com> wrote:
>> On Mon, Oct 9, 2017 at 8:46 AM, Mark Rutland <mark.rut
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 forward to using this! :)
;
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Alexander Popov <alex.po...@linux.com>
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
l call with corresponding argument value.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation
From: Victor Chibotaru <tch...@google.com>
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com&
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: linux
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
l call with corresponding argument value.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation
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: linux
On Mon, Oct 9, 2017 at 8:46 AM, Mark Rutland <mark.rutl...@arm.com> 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:
>> +/*
>> + * Define
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
On Mon, Oct 9, 2017 at 8:53 AM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote:
>
>
> On 10/09/2017 06:05 PM, Alexander Potapenko wrote:
>
>> v2: - updated KCOV_ENABLE_COMPARISONS description
>> ---
>> Makefile | 5 +++--
>> lib/Kc
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
;
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Alexander Popov <alex.po...@linux.com>
From: Victor Chibotaru <tch...@google.com>
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com&
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
;
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Alexander Popov <alex.po...@linux.com>
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 <tch...@google.com>
The updated documentation describes new KCOV mode for collecting
comparison operands.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com&
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
l call with corresponding argument value.
Signed-off-by: Victor Chibotaru <tch...@google.com>
Signed-off-by: Alexander Potapenko <gli...@google.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Andrey Konovalov <andreyk...@google.com>
Cc: Andrew Morton <a...@linux-foundation
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: linux
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Signed
On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
&
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:
>>>
>>&
tun->flags & TUN_TYPE_MASK) {
>> case IFF_TUN:
>> if (tun->flags & IFF_NO_PI) {
>> - switch (skb->data[0] & 0xf0) {
>> - case 0x40:
>> + u8 ip_proto = skb->len ? (skb->data[0] >&g
se 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 name this va
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Signed-
On Tue, Sep 26, 2017 at 5:02 PM, 'Eric Dumazet' via syzkaller
<syzkal...@googlegroups.com> wrote:
> On Tue, Sep 26, 2017 at 7:53 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
>> sk
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 skb is empt
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sign
(, 0, sizeof(struct ifreq));
strcpy((char*)_name, "gre0");
req.ifr_flags = IFF_UP | IFF_MULTICAST;
ioctl(tun_fd, TUNSETIFF, );
ioctl(sock, SIOCSIFFLAGS, "gre0");
write(tun_fd, "hi", 0);
return 0;
}
======
Sig
On Tue, Sep 19, 2017 at 2:55 PM, Alexander Potapenko <gli...@google.com> wrote:
> On Tue, Sep 19, 2017 at 11:45 AM, Josh Poimboeuf <jpoim...@redhat.com> wrote:
>> For inline asm statements which have a CALL instruction, we list the
>> stack pointer as a constrain
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
[sp]"="(tmp)
> #endif
> - "+r"(__sp)
> :
> [entry]"r"(entry),
> [ss]"i"(__KERNEL_DS),
> diff --git a/arch/x86/mm/fault.c b/arch/x86
ot;(__sp)
> :
> [entry]"r"(entry),
> [ss]"i"(__KERNEL_DS),
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index b836a7274e12..4457e41378e4 100644
> --- a/arch/x86/mm/fault.c
>
ned longs.
>> + */
>> + area = (u64 *)t->kcov_area;
>> + max_pos = t->kcov_size * sizeof(unsigned long);
>
> Perhaps it would make more sense for k->kcov_size to be in bytes, if
> different options will have differing record sizes?
>
>> +
>> + count = READ_ONCE(area[0]);
>> +
>> + /* Every record is KCOV_WORDS_PER_CMP words. */
>
> As above, please be explicit about what a "word" is, or avoid using
> "word" terminology.
>
> Thanks,
> Mark.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller+unsubscr...@googlegroups.com.
> 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
signed longs.
>> + */
>> + area = (u64 *)t->kcov_area;
>> + max_pos = t->kcov_size * sizeof(unsigned long);
>
> Perhaps it would make more sense for k->kcov_size to be in bytes, if
> different options will have differing record sizes?
>
>> +
&g
Commit-ID: 187e91fe5e915f4b7f39b824aa422493463e443d
Gitweb: http://git.kernel.org/tip/187e91fe5e915f4b7f39b824aa422493463e443d
Author: Alexander Potapenko <gli...@google.com>
AuthorDate: Wed, 16 Aug 2017 21:08:08 +0200
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
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
On Wed, Aug 16, 2017 at 9:08 PM, Alexander Potapenko <gli...@google.com> 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.
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 generating
a R_X86_64_32S, which led to
accessing invalid memory and rebooting the kernel.
Cc: Kirill A. Shutemov <kirill.shute...@linux.intel.com>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Michael Davidson <m...@google.com>
Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C&quo
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 file
.c:292
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
Reviewed-by: Xin Long <lucien@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
---
v3: set flowinfo between port and addr to ease code review.
v2 is id
.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
On Tue, Aug 8, 2017 at 8:47 PM, Marcelo Ricardo Leitner
<marcelo.leit...@gmail.com> 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 sc
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
.c:292
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
Reviewed-by: Xin Long <lucien@gmail.com>
---
v2 is identical to v1, resending per request by Marcelo Ricardo Leitner.
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
dif
.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 Wed, Jul 19, 2017 at 2:58 AM, Xin Long <lucien@gmail.com> wrote:
> On Wed, Jul 19, 2017 at 3:02 AM, Alexander Potapenko <gli...@google.com>
> wrote:
>> On Tue, Jul 18, 2017 at 4:55 PM, Alexander Potapenko <gli...@google.com>
>> wrote:
>>> KMSA
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
&
e info.first_bad_addr in kasan_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
>
--
Al
> 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
memory). Therefore the loop condition is always true,
and the loops become infinite.
To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.
Signed-off-by: Alexander Potapenko <gli...@google.com>
memory). Therefore the loop condition is always true,
and the loops become infinite.
To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.
Signed-off-by: Alexander Potapenko
---
include/linux/llist.
On Tue, Jul 18, 2017 at 4:55 PM, Alexander Potapenko <gli...@google.com> 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).
> Make sure all fields of an IPv6 address are initialize
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
> sctp_addr->v6.sin6_scope_id in sctp_v6_cmp_addr() (see below).
> Make sure all fields of an IPv6 address are initialized, which
> guarantees th
.c:292
==
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 2a186b201ad2..a15d691829c6 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6
.c:292
==
Signed-off-by: Alexander Potapenko
---
net/sctp/ipv6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 2a186b201ad2..a15d691829c6 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -513,6 +513,8 @@ stati
On Mon, Jul 17, 2017 at 12:35 PM, Alexander Potapenko <gli...@google.com> wrote:
> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
> which originated from the TCP request socket created in
>
On Mon, Jul 17, 2017 at 12:35 PM, Alexander Potapenko wrote:
> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
> which originated from the TCP request socket created in
> cookie_v6_check():
>
> =
().
Signed-off-by: Alexander Potapenko <gli...@google.com>
Fixes: 58d607d3e52f ("tcp: provide skb->hash to synack packets")
---
net/ipv4/syncookies.c | 1 +
net/ipv6/syncookies.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
().
Signed-off-by: Alexander Potapenko
Fixes: 58d607d3e52f ("tcp: provide skb->hash to synack packets")
---
net/ipv4/syncookies.c | 1 +
net/ipv6/syncookies.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 0905cf04c2a4..03ad87
On Fri, Jul 14, 2017 at 7:54 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 19:33:54 +0200
>
>> On Fri, Jul 14, 2017 at 7:23 PM, David Miller <da...@davemloft.net> wrote:
>>> Fr
On Fri, Jul 14, 2017 at 7:54 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 19:33:54 +0200
>
>> On Fri, Jul 14, 2017 at 7:23 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Fri, 14 Jul 2017 18:33:01 +0200
>>
On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell <ncardw...@google.com> wrote:
> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko <gli...@google.com>
> wrote:
>> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
>> which originated from
On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell wrote:
> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko
> wrote:
>> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(),
>> which originated from the TCP request socket created in
>> cookie_v6_che
On Fri, Jul 14, 2017 at 7:23 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 18:33:01 +0200
>
>> On Fri, Jul 14, 2017 at 5:58 PM, David Miller <da...@davemloft.net> wrote:
>>> Fr
On Fri, Jul 14, 2017 at 7:23 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 18:33:01 +0200
>
>> On Fri, Jul 14, 2017 at 5:58 PM, David Miller wrote:
>>> From: Alexander Potapenko
>>> Date: Fri, 14 Jul 2017 12:03:29 +0200
>>&g
process_backlog+0x667/0xba0 net/core/dev.c:4866
napi_poll net/core/dev.c:5268
net_rx_action+0xc95/0x1590 net/core/dev.c:5333
__do_softirq+0x485/0x942 kernel/softirq.c:284
==
Signed-off-by: Alexander Potapenko <gli...@google.
process_backlog+0x667/0xba0 net/core/dev.c:4866
napi_poll net/core/dev.c:5268
net_rx_action+0xc95/0x1590 net/core/dev.c:5333
__do_softirq+0x485/0x942 kernel/softirq.c:284
==
Signed-off-by: Alexander Potapenko
---
net/ipv6
On Fri, Jul 14, 2017 at 5:58 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Fri, 14 Jul 2017 12:03:29 +0200
>
>> v2: per comment from David Miller, make sure the whole iterator->length
>> fits i
On Fri, Jul 14, 2017 at 5:58 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Fri, 14 Jul 2017 12:03:29 +0200
>
>> v2: per comment from David Miller, make sure the whole iterator->length
>> fits into the remaining buffer.
>
> Please compile and
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v3: fix compilation
v2: per comment from David Miller, make sure the whole iterator->length
f
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko
---
v3: fix compilation
v2: per comment from David Miller, make sure the whole iterator->length
fits into the remaining buffer
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko <gli...@google.com>
---
v2: per comment from David Miller, make sure the whole iterator->length
fits into the remaining
_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
======
Signed-off-by: Alexander Potapenko
---
v2: per comment from David Miller, make sure the whole iterator->length
fits into the remaining buffer.
---
include/net/
On Thu, Jul 13, 2017 at 8:32 PM, David Miller <da...@davemloft.net> wrote:
> From: Alexander Potapenko <gli...@google.com>
> Date: Thu, 13 Jul 2017 20:10:34 +0200
>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index a9519a06a23b..f13632e
On Thu, Jul 13, 2017 at 8:32 PM, David Miller wrote:
> From: Alexander Potapenko
> Date: Thu, 13 Jul 2017 20:10:34 +0200
>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index a9519a06a23b..f13632ee33f0 100644
>> --- a/include/net/sctp/sctp.
On Thu, Jul 13, 2017 at 8:14 PM, Alexander Potapenko <gli...@google.com> wrote:
> On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko <gli...@google.com>
> wrote:
>> If the iterator (|pos.p| or |err|) has already reached the end of
>> chunk, we shouldn't access it
On Thu, Jul 13, 2017 at 8:14 PM, Alexander Potapenko wrote:
> On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko
> wrote:
>> If the iterator (|pos.p| or |err|) has already reached the end of
>> chunk, we shouldn't access iterator->length.
>>
>> Th
On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko <gli...@google.com> wrote:
> If the iterator (|pos.p| or |err|) has already reached the end of
> chunk, we shouldn't access iterator->length.
>
> This bug has been detected by KMSAN. For the following pair of system
On Thu, Jul 13, 2017 at 8:10 PM, Alexander Potapenko wrote:
> If the iterator (|pos.p| or |err|) has already reached the end of
> chunk, we shouldn't access iterator->length.
>
> This bug has been detected by KMSAN. For the following pair of system
> calls:
>
> sock
301 - 400 of 1004 matches
Mail list logo
