On Fri, Oct 4, 2013 at 12:57 AM, Al Viro wrote:
> On Thu, Oct 03, 2013 at 12:36:08PM -0700, Kees Cook wrote:
>> > Kees, try to think for a minute[1]. Really. We have general-purpose
>> > ...
>> > [1] yes, yes, I know - the mere mention of security should've prevented
>> > such
>> > arrogant req
On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger
wrote:
> ...
> [1] yes, yes, I know - the mere mention of security should've prevented
> such
> arrogant requests. It's an imperfect universe.
I want to attempt to disassemble what you've communicating here:
>>
Hi,
I am working on AddressSanitizer -- a tool that detects use-after-free
and out-of-bounds bugs
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
Here is one of the use-after-free reports:
[ 296.869705] ERROR: AddressSanitizer: heap-use-after-free on address
88
On Wed, Sep 11, 2013 at 2:06 AM, Andi Kleen wrote:
>> Indeed, get_wchan ensures that fp> fp+8:
>>
>> 434 if (fp < (unsigned long)stack ||
>> 435 fp >= (unsigned long)stack+THREAD_SIZE)
>> 436 return 0;
>> 437 ip = *(u64 *)
355] Shadow gap:fe
On Fri, Aug 23, 2013 at 7:48 PM, Dmitry Vyukov wrote:
> On Wed, Aug 21, 2013 at 8:35 PM, Dmitry Vyukov wrote:
>> Hi,
>>
>> I'm working on a memory error detector AddressSanitizer for Linux
>> kernel
>> (https:/
Hi,
We are working on a memory error detector AddressSanitizer for Linux
kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
it can detect use-after-free and buffer-overflow errors.
Here is a new report from the tool:
[ 124.575597] ERROR: AddressSanitizer: heap
On Wed, Sep 4, 2013 at 12:27 AM, Dan Aloni wrote:
> On Tue, Sep 03, 2013 at 05:49:03PM +0400, Dmitry Vyukov wrote:
>> Is anybody reading this? Is it a correct place to post such things?
>> Maybe there is a more appropriate place?
>
> This is the correct place, and people are
On Fri, Sep 13, 2013 at 3:03 AM, Wolfram Gloger
wrote:
> "H. Peter Anvin" writes:
>
>> Actually, the sanest would be:
>>
>> if (fp < (unsigned long)stack ||
>> fp >= (unsigned long)stack+(THREAD_SIZE-16))
>>
>> ... wouldn't it (since we are accessing an 8-byte datum at offset +8?
On Fri, Sep 13, 2013 at 3:03 AM, Wolfram Gloger
wrote:
> "H. Peter Anvin" writes:
>
>> Actually, the sanest would be:
>>
>> if (fp < (unsigned long)stack ||
>> fp >= (unsigned long)stack+(THREAD_SIZE-16))
>>
>> ... wouldn't it (since we are accessing an 8-byte datum at offset +8?
Hi,
I'm working on a memory error detector AddressSanitizer for Linux
kernel
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
it can detect use-after-free and buffer-overflow errors. Currently the
tool is in very early stage and it can contain bugs.
Here is one of th
On Wed, Aug 21, 2013 at 8:35 PM, Dmitry Vyukov wrote:
> Hi,
>
> I'm working on a memory error detector AddressSanitizer for Linux
> kernel
> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
> it can detect use-after-free and buffer-overflo
On Mon, Jun 20, 2016 at 3:31 PM, Jan Kara wrote:
> Hi,
>
> On Fri 17-06-16 12:04:05, Tejun Heo wrote:
>> 43d1c0eb7e11 ("block: detach bdev inode from its wb in
>> __blkdev_put()") detached bdev inode from its wb as the bdev inode may
>> outlive the underlying bdi and thus the wb. This is accompli
On Mon, Jun 20, 2016 at 7:40 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jun 20, 2016 at 03:38:41PM +0200, Dmitry Vyukov wrote:
>> > Sorry for the late reply but now when thinking about the patch I don't
>> > think it is quite right. Writeback can happen from o
Hello,
The following program triggers use-after-free in kvm_irqfd_release:
BUG: KASAN: use-after-free in do_raw_spin_lock+0x281/0x2b0 at addr
880060888c64
Read of size 4 by task a.out/7084
page:ea0001822200 count:0 mapcount:-127 mapping: (null) index:0x0
flags: 0x4fffe00(
Hello,
The following program triggers GPF in kvm_lapic_set_tpr:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 0 PID: 7683 Comm: syz-executor Not tainted 4.
On Mon, Jun 6, 2016 at 6:39 PM, Takashi Iwai wrote:
> On Mon, 06 Jun 2016 18:29:25 +0200,
> Dmitry Vyukov wrote:
>>
>> On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote:
>> > On Sat, 04 Jun 2016 20:27:50 +0200,
>> > Dmitry Vyukov wrote:
>> >>
>
On Tue, May 31, 2016 at 11:56 AM, Paolo Bonzini wrote:
>
>
> On 15/02/2016 14:30, Dmitry Vyukov wrote:
>> *(uint32_t*)0x2000a6b9 = (uint32_t)0x3e;
>> *(uint16_t*)0x2000a6bd = (uint16_t)0x8;
>> *(uint8_t*)0x2000a6bf = (uint8_t)0x8d4;
>>
On Mon, Jun 6, 2016 at 4:11 PM, Takashi Iwai wrote:
> On Sat, 04 Jun 2016 20:27:50 +0200,
> Dmitry Vyukov wrote:
>>
>> On Sat, Jun 4, 2016 at 8:00 PM, Dmitry Vyukov wrote:
>> > Hello,
>> >
>> > The following program triggers use-after-free:
>>
Alexander Potapenko
Acked-by: Dmitry Vyukov
> ---
> lib/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 5dc77a8..cbac596 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -180,6 +180,7 @@ obj-$(CONFIG_IRQ_P
KASAN put hard/soft IRQ entries into
separate sections")
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Dmitry Vyukov
---
scripts/recordmcount.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index 42396a7..a68f031 100644
--- a/scripts/
87e ("arch, ftrace: for KASAN put hard/soft IRQ entries into
separate sections")
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Dmitry Vyukov
Acked-by: Steve Rostedt
---
Changes from v1:
- updated recordmcount.pl as well
---
scripts/recordmcount.c | 1 +
scripts/recordmcount.pl |
On Mon, Sep 26, 2016 at 5:06 PM, Steven Rostedt wrote:
> On Mon, 26 Sep 2016 11:02:36 -0400
> Steven Rostedt wrote:
>
>> > ---
>> > scripts/recordmcount.c | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
>> > index 42396a7..a68f031
On Mon, Sep 26, 2016 at 5:10 PM, Dmitry Vyukov wrote:
> Commit "arch, ftrace: for KASAN put hard/soft IRQ entries into separate
> sections"
> added .softirqentry.text section, but it was not added to recordmcount.
> So functions in the section are untracable.
> A
On Tue, Sep 27, 2016 at 1:32 AM, Andrew Morton
wrote:
> On Fri, 23 Sep 2016 16:51:13 +0200 Andrey Konovalov
> wrote:
>
>> in_interrupt() returns a nonzero value when we are either in an
>> interrupt or have bh disabled via local_bh_disable(). Since we are
>> interested in only ignoring coverage
On Tue, Sep 27, 2016 at 9:34 AM, Peter Zijlstra wrote:
> On Tue, Sep 27, 2016 at 08:21:32AM +0200, Dmitry Vyukov wrote:
>>
>> I suspect there is a bunch of places that use in_interrupt(), but mean
>> the same as KCOV wants -- am I in interrupt? and not am I in interrupt
&g
On Tue, Sep 27, 2016 at 12:59 PM, Peter Zijlstra wrote:
> On Tue, Sep 27, 2016 at 09:50:41AM +0200, Dmitry Vyukov wrote:
>> On Tue, Sep 27, 2016 at 9:34 AM, Peter Zijlstra wrote:
>> > On Tue, Sep 27, 2016 at 08:21:32AM +0200, Dmitry Vyukov wrote:
>> >>
>> >
On Fri, Jul 29, 2016 at 7:57 PM, Vegard Nossum wrote:
> Hi guys,
>
> I ran into this one on commit c624c86615fb8aa61fa76ed8c935446d06c80e77:
>
> [ cut here ]
> kernel BUG at mm/mempolicy.c:1699!
> invalid opcode: [#1] PREEMPT SMP KASAN
> Dumping ftrace buffer:
>(ft
On Fri, Jul 29, 2016 at 9:10 PM, Vegard Nossum wrote:
> On 07/29/2016 08:05 PM, Dmitry Vyukov wrote:
>>
>> On Fri, Jul 29, 2016 at 7:57 PM, Vegard Nossum
>> wrote:
>>>
>>> [ cut here ]
>>> kernel BUG at mm/mempoli
Do you use SLAB or SLUB? Is CONFIG_STACKDEPOT enabled? Kernel revision?
On Fri, Jul 29, 2016 at 10:17 PM, Vegard Nossum
wrote:
> Hi again,
>
> I am seeing some KASAN use-after-free bugs now but there is no
> stacktrace for where they were freed anymore:
>
> BUG: KASAN: use-after-free in acct_coll
On Wed, Sep 7, 2016 at 1:11 AM, Daniel Borkmann wrote:
> On 09/06/2016 11:03 PM, Kees Cook wrote:
>>
>> On Sat, Sep 3, 2016 at 8:15 AM, Dmitry Vyukov wrote:
>>>
>>> Hello,
>>>
>>> While running syzkaller fuzzer I've got the follow
On Wed, Sep 7, 2016 at 5:00 PM, Takashi Iwai wrote:
> On Tue, 06 Sep 2016 18:10:30 +0200,
> Takashi Iwai wrote:
>>
>> On Tue, 06 Sep 2016 16:06:08 +0200,
>> Dmitry Vyukov wrote:
>> >
>> > > Do you really see the zero-division error with sticks=1 fix?
On Thu, Sep 1, 2016 at 8:04 PM, Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 07:53:44PM +0200, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program:
>>
>> https://gist.githubusercontent.com/dvyukov/0952eeac71069b46b3fe0e28bd1a02bf/raw/396b9dcce2636ceca
Hello,
The following program:
https://gist.githubusercontent.com/dvyukov/0952eeac71069b46b3fe0e28bd1a02bf/raw/396b9dcce2636cecab1a4161c15d3f066e6ef639/gistfile1.txt
if run in a parallel loop creates unkillable hanged processes:
-bash-4.3# ps afxu | grep a.out
root 4489 0.0 0.0 8868 3
On Mon, Aug 29, 2016 at 8:05 AM, Daniel Vetter wrote:
> On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers WARNING in ioremap_wc:
>
> Yup, that should also be fixed in linux-next. Probably better to not
>
On Wed, Aug 24, 2016 at 3:03 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> +config VMAP_STACK
>> + default y
>> + bool "Use a virtually-mapped stack"
>> + depends on HAVE_ARCH_VMAP_STACK && !KASAN
>> + ---help---
>> + Enable this if you want the use virtually-mapp
On Thu, Nov 17, 2016 at 8:52 AM, Dmitry Vyukov wrote:
> On Wed, Nov 16, 2016 at 10:27 PM, Quentin Casasnovas
> wrote:
>> AFL uses a fixed-size buffer (typically 64 KiB) where each byte is
>> a counter representing how many times an A -> B branch was taken.
>> Of course
uld it be static?"
>
> Signed-off-by: Colin Ian King
Acked-by: Dmitry Vyukov
> ---
> mm/kasan/report.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index beee0e980e2d..04bb1d3eb9ec 100644
>
On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka wrote:
> Hi
>
> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>> I've got the following report while fuzzing the kernel with syzkaller.
>>
>> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>
>> I'm not sure whe
On Mon, Oct 16, 2017 at 12:27 PM, Kalle Valo wrote:
> Dmitry Vyukov writes:
>
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
>> wrote:
>>> Hi
>>>
>>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>>> I&
On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka wrote:
> Hi Dmitry
>
> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka
>> wrote:
>> > Hi
>> >
>> > On Mon, Oct 09,
On Tue, Oct 17, 2017 at 5:38 PM, Chase Bertke wrote:
> Hello,
>
> I would like to report a bug found via syzkaller on version 4.13.0-rc4. I
> have searched the syzkaller mailing list and did not see any other reports
> for this bug.
>
> Please see below:
>
> ===
It is completely unused and implemented only on x86.
Remove it.
Signed-off-by: Dmitry Vyukov
Suggested-by: Mark Rutland
Cc: Andrey Ryabinin
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: Andrew Morton
Cc: linux-kernel@vger.kernel.org
Cc: x...@
racy use-after-free.
Add manual KASAN checks to atomic operations.
Signed-off-by: Dmitry Vyukov
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon ,
Cc: Andrew Morton ,
Cc: Andrey Ryabinin ,
Cc: Ingo Molnar ,
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
Cc: linux-kernel
Currently kasan_check_read/write() accept 'const void*', make them
accept 'const volatile void*'. This is required for instrumentation
of atomic operations and there is just no reason to not allow that.
Signed-off-by: Dmitry Vyukov
Cc: Mark Rutland
Cc: Andrey Ryabinin
Cc:
CPP turns perfectly readable code into an unreadable,
unmaintainable mess. Ingo suggested to write them out as-is.
Do this.
Signed-off-by: Dmitry Vyukov
Suggested-by: Ingo Molnar
Cc: Mark Rutland
Cc: Andrey Ryabinin
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Add arch_ prefix to all atomic operations and include
. This will allow
to add KASAN instrumentation to all atomic ops.
Signed-off-by: Dmitry Vyukov
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Ingo Molnar
Cc: kasan-...@googlegroups.com
Cc
The comments are factored out from the code changes to make them
easier to read. Add them separately to explain some non-obvious
aspects.
Signed-off-by: Dmitry Vyukov
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Ingo Molnar
Cc: kasan
t;x86: remove unused atomic_inc_short()" patch
it is mailed separately
- rebased on top of tip/locking/core head
- other changes noted within individual patches
Dmitry Vyukov (7):
x86: un-macro-ify atomic ops implementation
x86: use long long for 64-bit atomic ops
asm-generic:
The new header allows to wrap per-arch atomic operations
and add common functionality to all of them.
Signed-off-by: Dmitry Vyukov
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Ingo Molnar
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
ormat specifier that prints result of
atomic64_read() without warnings. atomic64_try_cmpxchg() is almost
impossible to use in portable fashion because it requires either
'long *' or 'long long *' as argument depending on arch.
Switch arch/x86/include/asm/atomic64_64.h to '
On Wed, Mar 29, 2017 at 3:37 PM, Mark Rutland wrote:
> On Tue, Mar 28, 2017 at 06:25:07PM +0200, Dmitry Vyukov wrote:
>> On Tue, Mar 28, 2017 at 6:15 PM, Dmitry Vyukov wrote:
>
>> > #define __try_cmpxchg(ptr, pold, new, size)\
>> >
On Tue, Mar 28, 2017 at 11:32 PM, Matthew Wilcox wrote:
> On Tue, Mar 28, 2017 at 06:15:40PM +0200, Dmitry Vyukov wrote:
>> @@ -193,12 +193,12 @@ static inline long atomic64_xchg(atomic64_t *v, long
>> new)
>> * @a: the amount to add to v...
>> * @u
On Sun, May 28, 2017 at 1:02 AM, wrote:
> On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov wrote:
>>Some 64-bit atomic operations use 'long long' as operand/return type
>>(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);
>>while others use &#
On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
wrote:
> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 0bf81e837cbf..c795207d8a3c 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -100,7 +100,7 @
On Mon, May 29, 2017 at 12:49 PM, Heiko Carstens
wrote:
> On Fri, May 26, 2017 at 09:09:04PM +0200, Dmitry Vyukov wrote:
>> Some 64-bit atomic operations use 'long long' as operand/return type
>> (e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);
>&g
On Mon, May 29, 2017 at 1:18 PM, Andrey Ryabinin
wrote:
>
>
> On 05/29/2017 01:02 PM, Dmitry Vyukov wrote:
>> On Sat, May 27, 2017 at 12:10 AM, Kirill A. Shutemov
>> wrote:
>>> On Thu, May 25, 2017 at 11:33:33PM +0300, Kirill A. Shutemov wrote:
>>>>
On Sun, May 28, 2017 at 11:34 AM, wrote:
> On May 28, 2017 2:29:32 AM PDT, Dmitry Vyukov wrote:
>>On Sun, May 28, 2017 at 1:02 AM, wrote:
>>> On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov
>>wrote:
>>>>Some 64-bit atomic operations use 'long long'
On Mon, Apr 10, 2017 at 11:07 PM, Cong Wang wrote:
> On Mon, Apr 10, 2017 at 7:37 AM, Andrey Konovalov
> wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 39da7c509acff13fc8cb12ec1bb20337c988ed36 (4.11-rc6).
>>
>> Unfortunately it's
On Fri, Apr 28, 2017 at 8:19 AM, Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 3:17 PM, Dmitry Vyukov wrote:
>> On Sun, Mar 5, 2017 at 8:18 PM, Al Viro wrote:
>>> On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote:
>>>
>>>> Added more debug
On Thu, May 25, 2017 at 2:41 AM, Joonsoo Kim wrote:
> On Wed, May 24, 2017 at 07:19:50PM +0200, Dmitry Vyukov wrote:
>> On Wed, May 24, 2017 at 9:45 AM, Joonsoo Kim wrote:
>> >> > What does make your current patch work then?
>> >> > Say we map a new sha
On Mon, May 29, 2017 at 5:07 PM, Dmitry Vyukov wrote:
> On Thu, May 25, 2017 at 2:41 AM, Joonsoo Kim wrote:
>> On Wed, May 24, 2017 at 07:19:50PM +0200, Dmitry Vyukov wrote:
>>> On Wed, May 24, 2017 at 9:45 AM, Joonsoo Kim wrote:
>>> >> > What do
On Mon, May 29, 2017 at 5:12 PM, Dmitry Vyukov wrote:
>>>> >> > What does make your current patch work then?
>>>> >> > Say we map a new shadow page, update the page shadow to say that there
>>>> >> > is mapped shadow. Then another CP
On Tue, May 30, 2017 at 9:58 AM, Vladimir Murzin
wrote:
> On 29/05/17 16:29, Dmitry Vyukov wrote:
>> I have an alternative proposal. It should be conceptually simpler and
>> also less arch-dependent. But I don't know if I miss something
>> important that will render it
On Tue, May 30, 2017 at 8:24 AM, Al Viro wrote:
> On Mon, May 29, 2017 at 04:48:17PM +0200, Dmitry Vyukov wrote:
>
>> Al, do you want me to mail the patch?
>> I won't be able to write a super detailed description, but I can do
>> some format patch.
>
> It'
On Tue, May 30, 2017 at 10:40 AM, Vladimir Murzin
wrote:
> On 30/05/17 09:31, Vladimir Murzin wrote:
>> [This sender failed our fraud detection checks and may not be who they
>> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>>
>> On 30/05/17
On Wed, May 3, 2017 at 2:01 PM, Greg KH wrote:
>> >>> So the original problem is that the vmalloc() in n_tty_open() can
>> >>> fail, and that will panic in tty_set_ldisc()/tty_ldisc_restore()
>> >>> because of its unwillingness to proceed if the tty doesn't have an
>> >>> ldisc.
>> >>>
>> >>> Dmit
utSpoofing]
>>>>
>>>> On 30/05/17 09:15, Dmitry Vyukov wrote:
>>>>> On Tue, May 30, 2017 at 9:58 AM, Vladimir Murzin
>>>>> wrote:
>>>>>> On 29/05/17 16:29, Dmitry Vyukov wrote:
>>>>>>> I have a
On Tue, May 30, 2017 at 11:39 AM, Vladimir Murzin
wrote:
>
> On 30/05/17 10:26, Dmitry Vyukov wrote:
> > On Tue, May 30, 2017 at 11:08 AM, Vladimir Murzin
> > wrote:
> >>> wrote:
> >>>> On 30/05/17 09:31, Vladimir Murzin wrote:
> >>>>
Peter, is this dup of "WARNING in get_pi_state"?
https://groups.google.com/d/msg/syzkaller-bugs/jpui-7LJvUw/b77s8UZiAgAJ
On Tue, Oct 31, 2017 at 2:43 PM, syzbot
wrote:
>> #syz upstream
>
>
> Can't upstream, this is final destination.
>
>
>
>> On Mon, Oct 30, 2017 at 10:53 PM, syzbot
>>
>> wrote:
On Tue, Oct 31, 2017 at 3:00 PM, Vlastimil Babka wrote:
> On 10/30/2017 08:15 PM, Dmitry Vyukov wrote:
>> On Mon, Oct 30, 2017 at 10:12 PM, syzbot
>>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 887c8ba753fbe809
On Tue, Oct 31, 2017 at 3:45 PM, Chris Wilson wrote:
> Quoting syzbot (2017-10-27 09:09:50)
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug repor
On Tue, Oct 31, 2017 at 3:53 PM, Haozhong Zhang
wrote:
> Hi Wanpeng,
>
> On 10/31/17 19:10 +0800, Wanpeng Li wrote:
>> 2017-10-31 17:59 GMT+08:00 Dmitry Vyukov :
>> > Hello,
>> >
>> > I am seeing the following crash on upstream
>> &g
On Tue, Oct 31, 2017 at 4:02 PM, Peter Zijlstra wrote:
> On Tue, Oct 31, 2017 at 02:49:02PM +0300, Dmitry Vyukov wrote:
>> Peter, is this dup of "WARNING in get_pi_state"?
>> https://groups.google.com/d/msg/syzkaller-bugs/jpui-7LJvUw/b77s8UZiAgAJ
>
> Yep, same race,
On Tue, Oct 31, 2017 at 3:54 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 833e0e2f24fd0525090878f71e129a8a4cb8bf78
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 31, 2017 at 3:54 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 9506597de2cde02d48c11d5c250250b9143f59f7
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
rk+0xbfd/0x1be0 kernel/workqueue.c:2098
worker_thread+0x223/0x1860 kernel/workqueue.c:2233
kthread+0x39c/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
On Mon, Oct 30, 2017 at 10:34 PM, Dmitry Vyukov wrote:
> On Mon, Oct 30, 2017 at 10:32 PM, syzbot
>
: ffda RBX: 0005 RCX: 00446749
RDX: 0001 RSI: 20917ff0 RDI: 0005
RBP: 0086 R08: R09:
R10: R11: 0292 R12:
On Tue, Oct 31, 2017 at 4:21 PM, Dmitry Vy
On Tue, Oct 31, 2017 at 4:51 PM, Peter Zijlstra wrote:
> On Tue, Oct 31, 2017 at 02:13:33PM +0100, Michal Hocko wrote:
>> On Mon 30-10-17 16:10:09, Peter Zijlstra wrote:
>
>> > However, that splat translates like:
>> >
>> > __cpuhp_setup_state()
>> > #0cpus_read_lock()
>> > __cpuhp_s
On Tue, Oct 31, 2017 at 4:51 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0b5477d9dabd96ded4c5ef7a5f08b00188fc1dec
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 31, 2017 at 7:34 PM, Oleg Nesterov wrote:
> On 10/30, Dmitry Vyukov wrote:
>>
>> On Mon, Oct 30, 2017 at 10:12 PM, syzbot
>>
>> wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > d95e159cd1da1ed4dbf7
On Tue, Oct 31, 2017 at 5:54 PM, Vlastimil Babka wrote:
> On 10/31/2017 02:20 PM, Dmitry Vyukov wrote:
>> On Tue, Oct 31, 2017 at 3:54 PM, syzbot
>>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 9506597de2cde02d48
On Wed, Nov 1, 2017 at 9:38 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> fc2e8b1a47c14b22c33eb087fca0db58e1f4ed0e
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Wed, Nov 1, 2017 at 9:48 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 720bbe532b7c8f5613b48dea627fc58ed9ace707
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is a
On Wed, Nov 1, 2017 at 10:01 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> e19b205be43d11bff638cad4487008c48d21c103
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Wed, Nov 1, 2017 at 10:54 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 1d53d908b79d7870d89063062584eead4cf83448
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
On Wed, Nov 1, 2017 at 11:05 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 045c5205823fc3cd4e5cafdedb2cc7d434424909
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
On Wed, Nov 1, 2017 at 11:17 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> aae4e7a8bc44722fe70d58920a36916b1043195e
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 24, 2017 at 4:59 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> aa69ff9e9c32db8aa84835baffea1b70c39e5112
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 24, 2017 at 5:08 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 02a2b05395dde2f49eb67b51a5fbc6606943
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 24, 2017 at 5:20 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 80cee03bf1d626db0278271b505d7f5febb37bba
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Tue, Oct 24, 2017 at 7:06 PM, Cong Wang wrote:
> On Tue, Oct 24, 2017 at 8:02 AM, Dmitry Vyukov wrote:
>> On Tue, Oct 24, 2017 at 4:59 PM, syzbot
>>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> aa69ff9e9c32db8a
On Thu, Oct 26, 2017 at 10:18 AM, Stefan Hajnoczi wrote:
> On Tue, Oct 24, 2017 at 08:14:01AM -0700, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 28f50eb20931f32a2ceeb6aba8fa2cd5ca96ad9f
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
>> compiler
On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang wrote:
> Hi all,
>
> I am failed to reproduce it on target kernel with the reproducer file
> or replaying the target syzkaller description log file, do I made
> something wrong or there exists more subjects then the line in
> repro.txt:
>
> #{Threaded:
On Thu, Oct 26, 2017 at 5:49 PM, Xin Long wrote:
> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote:
>> On Thu, Oct 26, 2017 at 10:53 AM, ChunYu Wang wrote:
>>> Hi all,
>>>
>>> I am failed to reproduce it on target kernel with the reproducer file
&
On Thu, Oct 26, 2017 at 6:35 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 9829d9f31f6c0e4984545e03032f14ccca6eeb68
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
On Thu, Oct 26, 2017 at 6:35 PM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> ad9a19d003703ae06a6e8efc64cf26a939d9e84d
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is a
On Thu, Oct 26, 2017 at 7:58 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Oct 26, 2017 at 09:35:44AM -0700, syzbot wrote:
>> BUG: KASAN: use-after-free in __read_once_size
>> include/linux/compiler.h:276 [inline]
>> BUG: KASAN: use-after-free in atomic64_read
>> arch/x86/include/asm/atomic64_64.h:21
s case.
If it does not reproduce, it may be useful to run:
./syz-execprog -sandbox=namespace -procs=8 -repeat=0 saved.prog.file
i.e. repeat executing it in infinite loop with 8 parallel processes,
as lots of bugs are caused by races.
> On Thu, Oct 26, 2017 at 10:49 PM, Dmitry Vyukov wrote:
On Thu, Oct 26, 2017 at 6:56 PM, Xin Long wrote:
> Hi all,
>
> I am failed to reproduce it on target kernel with the reproducer file
> or replaying the target syzkaller description log file, do I made
> something wrong or there exists more subjects then the line in
> repro.
On Fri, Nov 10, 2017 at 7:49 PM, Cong Wang wrote:
> On Wed, Nov 8, 2017 at 5:00 AM, Dmitry Vyukov wrote:
>> On Wed, Nov 8, 2017 at 1:58 PM, syzbot
>>
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 7dfaa7bc99498da1
1 - 100 of 3641 matches
Mail list logo
