Fwd: Potential out-of-bounds in ftrace_regex_release

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). Below is one of the bug reports that I got while running trinity syscall fuzzer. Kernel is built on revision

Re: Fwd: Potential out-of-bounds in ftrace_regex_release

On Wed, Oct 2, 2013 at 10:57 PM, Dave Jones da...@redhat.com wrote: And that's the cause. I wonder what was being opened. Do you happen to have a trinity-child log for that thread ? Unfortunately not. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a

Re: Potential out-of-bounds in ftrace_regex_release

On Fri, Oct 18, 2013 at 11:09 PM, Steven Rostedt rost...@goodmis.org wrote: Can I assume that this is fixed? I'll put it in for 3.12 and mark it for stable too. I think yes. OK. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: Potential out-of-bounds in ftrace_regex_release

Testing now with your patch. I've seen this report only twice, so it will be difficult to say if it's not happening any more or just not triggered. On Thu, Oct 10, 2013 at 6:23 AM, Steven Rostedt rost...@goodmis.org wrote: On Wed, 9 Oct 2013 14:05:26 +0400 Andrey Konovalov andreyk...@google.com

Re: Fwd: Potential out-of-bounds in ftrace_regex_release

I got one more report of a similar bug: AddressSanitizer: heap-buffer-overflow on address 8800205f0e40 Write of size 1 by thread T14005: [811e2542] ftrace_event_write+0xe2/0x130 ./kernel/trace/trace_events.c:583 [8128c497] vfs_write+0x127/0x2f0 ??:0 [8128d572]

Potential data race in dput and __d_lookup

Hi We are working on a dynamic data race detector for Linux kernel called KernelThreadSanitizer (ktsan) (https://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerForKernel). Here is a report we got while running ktsan (upstream revision fc14f9c1272f62c3e8d01300f52467c0d9af50f9, Linux

Re: [PATCH v11 02/19] Add kernel address sanitizer infrastructure.

Sorry I didn't reply earlier. Signed-off-by: Andrey Konovalov adech...@gmail.com (Repeating in plain text.) On Wed, Feb 4, 2015 at 2:04 AM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 03 Feb 2015 20:42:55 +0300 Andrey Ryabinin a.ryabi...@samsung.com wrote: ... Based on work

[PATCH] x86: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

READ_ONCE and ASSIGN_ONCE) and 43239cbe79fc (kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)). Signed-off-by: Andrey Konovalov andreyk...@google.com --- arch/x86/include/asm/barrier.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/barrier.h

[PATCH v2] arch: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

in the commits 230fa253df63 (kernel: Provide READ_ONCE and ASSIGN_ONCE) and 43239cbe79fc (kernel: Change ASSIGN_ONCE(val, x) to WRITE_ONCE(x, val)). Signed-off-by: Andrey Konovalov andreyk...@google.com --- Changed in v2: - Other archs besides x86. arch/arm/include/asm/barrier.h | 4 ++-- arch

Potential data race in SyS_swapon

Hi! We are working on a dynamic data race detector for the Linux kernel called KernelThreadSanitizer (ktsan) (https://github.com/google/ktsan/wiki). While running ktsan on the upstream revision 21bdb584af8c with trinity we got a few reports from SyS_swapon, here is one of them:

Re: Potential data race in psmouse_interrupt

} == On Thu, Jul 23, 2015 at 3:08 PM, Pali Rohár pali.ro...@gmail.com wrote: On Wednesday 22 July 2015 15:14:42 Andrey Konovalov wrote: Hi! We are working on a dynamic data race detector for Linux kernel called KernelThreadSanitizer

Fwd: Potential data race in psmouse_interrupt

Hi! We are working on a dynamic data race detector for Linux kernel called KernelThreadSanitizer (ktsan) (https://github.com/google/ktsan/wiki). Here is a report we got while running ktsan (upstream revision 21bdb584af8cca7c6df3c44cba268be050a234eb).

Re: Multiple potential races on vma->vm_flags

On Wed, Oct 14, 2015 at 12:33 AM, Hugh Dickins wrote: > I think I've found the answer to that at last: we were indeed > all looking in the wrong direction. Your ktsan tree shows > > static __always_inline int atomic_add_negative(int i, atomic_t *v) > { > #ifndef CONFIG_KTSAN >

Potential use-after-free in shrink_page_list

Hi! While fuzzing the kernel (4.3-rc4) with KASAN and Trinity I got the following report: == BUG: KASan: use after free in shrink_page_list+0x93a/0xf10 at addr 88003487da80 Read of size 8 by task kswapd0/622

Re: [PATCH v5 04/23] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead

Hi Yury, With this patch set 4.3 kernel fails to build with both arch/arm64/configs/defconfig, and with arch/arm64/configs/defconfig plus CONFIG_AARCH32_EL0=y and CONFIG_ARM64_ILP32=y. See the details below. Thanks, Andrey On 09/30/2015 01:14 AM, Yury Norov wrote: From: Andrew Pinski

Re: [PATCH v5 10/23] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)

Hi Yury, With this patch set 4.3 kernel fails to build with arch/arm64/configs/defconfig plus CONFIG_AARCH32_EL0=y and CONFIG_ARM64_ILP32=y giving the following three errors (the 3d one is warning actually): -8<- 13:21:16 In file included from ../arch/arm64/kernel/process.c:48:0:

Re: [PATCH v5 03/23] arm64: rename COMPAT to AARCH32_EL0 in Kconfig

On 09/30/2015 01:14 AM, Yury Norov wrote: From: Andrew Pinski Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner Signed-off-by: Yury Norov diff

Fwd: Data race in __inode_add_bytes

Hi! We are working on a dynamic data race detector for the Linux kernel, KernelThreadSanitizer (ktsan): https://github.com/google/ktsan/wiki We got a report while running ktsan on 4.2: == ThreadSanitizer: data-race in

[PATCH 5/7] kasan: various fixes in documentation

Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- Documentation/kasan.txt | 43 ++- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt index 0d32355..d2f4c8f 100644 --- a/Documen

[PATCH 7/7] kasan: update reference to kasan prototype repo

Update the reference to the kasan prototype repository on github, since it was renamed. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/kasan.c | 2 +- mm/kasan/report.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/kasan/kasan.c b/mm

[PATCH 0/7] kasan: various fixes

. 2. Making references to the tool name consistent. We decided to use KASAN as the short name of the tool since a lot of people already use it, and KernelAddressSanitizer as the full name to be consistent with the userspace AddressSantizer. Andrey Konovalov (7): kasan: update reported bug types

[PATCH 3/7] kasan: accurately determine the type of the bad access

Makes KASAN accurately determine the type of the bad access. If the shadow byte value is in the [0, KASAN_SHADOW_SCALE_SIZE) range we can look at the next shadow byte to determine the type of the access. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.

[PATCH 2/7] kasan: update reported bug types for kernel memory accesses

Update the names of the bad access types to better reflect the type of the access that happended and make these error types "literals" that can be used for classification and deduplication in scripts. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kas

[PATCH 1/7] kasan: update reported bug types for not user nor kernel memory accesses

for this change. For userspace ASan we have a bunch of systems that analyze error types for the purpose of classification and deduplication. Sooner of later we will write them to KASAN as well. Then clearly and explicitly stated error types will bring value. Signed-off-by: Andrey Konovalov <andr

[PATCH 6/7] kasan: move KASAN_SANITIZE in arch/x86/boot/Makefile

Move KASAN_SANITIZE in arch/x86/boot/Makefile above the comment related to SVGA_MODE, since the comment refers to 'the next line'. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- arch/x86/boot/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ar

[PATCH 4/7] kasan: update log messages

We decided to use KASAN as the short name of the tool and KernelAddressSanitizer as the full one. Update log messages according to that. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- arch/x86/mm/kasan_init_64.c | 2 +- mm/kasan/kasan.c| 2 +- mm/kasan/re

Data race in ext4_writepages

Hi! We are working on a dynamic data race detector for the Linux kernel, KernelThreadSanitizer (ktsan): https://github.com/google/ktsan/wiki We got a report while running ktsan on 4.2: == ThreadSanitizer: data-race in

Fwd: Use-after-free in page_cache_async_readahead

On Thu, Sep 3, 2015 at 1:49 PM, Andrey Konovalov <andreyk...@google.com> wrote: > On Wed, Sep 2, 2015 at 9:40 PM, Tejun Heo <t...@kernel.org> wrote: >> Hello, Andrey. > > Hello Tejun, > >> On Wed, Sep 02, 2015 at 01:08:52PM +0200, Andrey Konovalov wrote: >>

Use-after-free in page_cache_async_readahead

Hi! While running KASAN on 4.2 with Trinity I got the following report: == BUG: KASan: use after free in page_cache_async_readahead+0x2cb/0x3f0 at addr 880034bf6690 Read of size 8 by task sshd/2571

Re: Use-after-free in page_cache_async_readahead

On Wed, Sep 2, 2015 at 9:40 PM, Tejun Heo <t...@kernel.org> wrote: > Hello, Andrey. Hello Tejun, > On Wed, Sep 02, 2015 at 01:08:52PM +0200, Andrey Konovalov wrote: >> While running KASAN on 4.2 with Trinity I got th

Potential data race in uart_ioctl

Hi! We are working on a dynamic data race detector for the Linux kernel called KernelThreadSanitizer (ktsan) (https://github.com/google/ktsan/wiki). While booting the kernel (upstream revision 21bdb584af8c) we got a report: ==

Re: Multiple potential races on vma->vm_flags

Can a vma be shared among a few mm's? If yes, then taking current->mm->mmap_sem to protect vma is not enough. In the first report below both T378 and T398 take current->mm->mmap_sem at mm/mlock.c:650, but they turn out to be different locks (the addresses are different). In the second report T309

[PATCH v2 0/7] kasan: various fixes

Andrey Konovalov (7): kasan: update reported bug types for not user nor kernel memory accesses kasan: update reported bug types for kernel memory accesses kasan: accurately determine the type of the bad access kasan: update log messages kasan: various fixes in documentation kasan: move

[PATCH v2 2/7] kasan: update reported bug types for kernel memory accesses

Update the names of the bad access types to better reflect the type of the access that happended and make these error types "literals" that can be used for classification and deduplication in scripts. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kas

[PATCH v2 6/7] kasan: move KASAN_SANITIZE in arch/x86/boot/Makefile

Move KASAN_SANITIZE in arch/x86/boot/Makefile above the comment related to SVGA_MODE, since the comment refers to 'the next line'. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- arch/x86/boot/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ar

[PATCH v2 1/7] kasan: update reported bug types for not user nor kernel memory accesses

for this change. For userspace ASan we have a bunch of systems that analyze error types for the purpose of classification and deduplication. Sooner of later we will write them to KASAN as well. Then clearly and explicitly stated error types will bring value. Signed-off-by: Andrey Konovalov <andr

[PATCH v2 4/7] kasan: update log messages

We decided to use KASAN as the short name of the tool and KernelAddressSanitizer as the full one. Update log messages according to that. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- arch/x86/mm/kasan_init_64.c | 2 +- mm/kasan/kasan.c| 2 +- mm/kasan/re

[PATCH v2 3/7] kasan: accurately determine the type of the bad access

Makes KASAN accurately determine the type of the bad access. If the shadow byte value is in the [0, KASAN_SHADOW_SCALE_SIZE) range we can look at the next shadow byte to determine the type of the access. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.

[PATCH v2 5/7] kasan: various fixes in documentation

Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- Documentation/kasan.txt | 43 ++- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt index 0d32355..d2f4c8f 100644 --- a/Documen

[PATCH v2 7/7] kasan: update reference to kasan prototype repo

Update the reference to the kasan prototype repository on github, since it was renamed. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/kasan.c | 2 +- mm/kasan/report.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/kasan/kasan.c b/mm

Use-after-free in kobject_put (scsi_host_dev_release)

Hi! While fuzzing the kernel (b8889c4fc6) with KASAN and Trinity I got the following report: (There are a few similar reports after this one, look here: https://gist.github.com/xairy/82746e5a5876d398a88c) == BUG: KASAN:

User-memory-access in ext4_orphan_del

Hi! While fuzzing the kernel (d25ed277fbd) with KASAN and Trinity I got the report below. This report is followed by: kernel BUG at fs/buffer.c:3025 BUG: KASan: use after free in mutex_optimistic_spin Crash log is here: https://gist.github.com/xairy/3b7fcf1cd2541c64c8d1 Here is another crash

Out-of-bounds in crc16 (ext4_group_desc_csum)

Hi! While fuzzing the kernel (b8889c4fc6) with KASAN and Trinity I got the following report: (There are many similar reports after this one with accessed addressed being increased) == BUG: KASan: out of bounds access in

Re: [PATCH v5 00/23] ILP32 for ARM64

On 10/01/2015 02:36 PM, Mark Brown wrote: On Thu, Oct 01, 2015 at 12:19:31PM +0100, Catalin Marinas wrote: On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote: Indeed. On that subject there was some discussion at Linaro Connect last week about work (being done outside Linaro, not

Re: Multiple potential races on vma->vm_flags

On Wed, Sep 23, 2015 at 3:39 AM, Hugh Dickins wrote: > This is totally untested, and one of you may quickly prove me wrong; > but I went in to fix your "Bad page state (mlocked)" by holding pte > lock across the down_read_trylock of mmap_sem in try_to_unmap_one(), > then

Re: Multiple potential races on vma->vm_flags

If anybody comes up with a patch to fix the original issue I easily can test it, since I'm hitting "BUG: Bad page state" in a second when fuzzing with KTSAN and Trinity. On Tue, Sep 15, 2015 at 9:01 PM, Kirill A. Shutemov wrote: > On Tue, Sep 15, 2015 at 01:36:45PM -0400,

Re: Multiple potential races on vma->vm_flags

On Tue, Sep 22, 2015 at 8:54 PM, Hugh Dickins <hu...@google.com> wrote: > On Tue, 22 Sep 2015, Andrey Konovalov wrote: >> If anybody comes up with a patch to fix the original issue I easily >> can test it, since I'm hitting "BUG: Bad page state" in a second when &g

[PATCH] midi: avoid freeing umidi object twice

ed-off-by: Andrey Konovalov <andreyk...@gmail.com> --- sound/usb/midi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/usb/midi.c b/sound/usb/midi.c index cc39f63..007cf58 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -2455,7 +2455,6 @@ int snd_usbmidi_create(struct sn

net/tcp: warning in tcp_try_coalesce/skb_try_coalesce

Hi, I've got the following error report while running the syzkaller fuzzer. On commit 566cf877a1fcb6d6dc0126b076aad062054c2637 (4.10-rc6). The fuzzer hits this issue quite often, but I don't have a working reproducer. WARNING: CPU: 3 PID: 7091 at net/core/skbuff.c:4331

Re: net/icmp: null-ptr-deref in ping_v4_push_pending_frames

On Mon, Feb 6, 2017 at 11:50 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Feb 6, 2017 at 11:39 AM, Andrey Konovalov <andreyk...@google.com> > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer. >>

net/icmp: null-ptr-deref in ping_v4_push_pending_frames

Hi, I've got the following error report while running the syzkaller fuzzer. The null-ptr-deref is caused by sendto() on a socket(PF_INET, SOCK_DGRAM, PROT_ICMP). Note, that this requires the ability to create such sockets, which can be configured by net.ipv4.ping_group_range

net: possible deadlock in skb_queue_tail

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10). Unfortunately I can't reproduce it. == [ INFO: possible circular locking dependency detected ]

Re: net/ipv6: use-after-free in sock_wfree

On Mon, Jan 9, 2017 at 6:21 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Jan 9, 2017 at 9:11 AM, Andrey Konovalov <andreyk...@google.com> > wrote: >> On Mon, Jan 9, 2017 at 6:08 PM, Andrey Konovalov <andreyk...@google.com> >> wrote: >>> Hi

Re: net/llc: bug in llc_pdu_init_as_xid_cmd/skb_over_panic

On Fri, Feb 10, 2017 at 4:12 PM, Andrey Konovalov <andreyk...@google.com> wrote: > Hi, > > I've got the following error report while fuzzing the kernel with syzkaller. > > On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. > > A reproducer and .config are attached

net/llc: BUG in llc_sap_state_process/skb_set_owner_r

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. A reproducer and .config are attached kernel BUG at ./include/linux/skbuff.h:2389! invalid opcode: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer

Re: net: BUG in __skb_gso_segment

On Mon, Feb 13, 2017 at 10:56 PM, Eric Dumazet <eduma...@google.com> wrote: > On Mon, Feb 13, 2017 at 11:54 AM, Andrey Konovalov > <andreyk...@google.com> wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >>

net/llc: bug in llc_pdu_init_as_xid_cmd/skb_over_panic

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. A reproducer and .config are attached kernel BUG at net/core/skbuff.c:105! invalid opcode: [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty)

[PATCH v2 5/9] kasan: change report header

The exact access address is not usually important, so move it to the second line. This also makes the header look visually balanced. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm

[PATCH v2 9/9] kasan: separate report parts by empty lines

Makes the report easier to read. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/kasan/report.c b/mm/kasan/report.c index 210131bc0a3c..718a10a48a19 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/re

[PATCH v2 4/9] kasan: simplify address description logic

Simplify logic for describing a memory address. Add addr_to_page() helper function. Makes the code easier to follow. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-)

[PATCH v2 2/9] kasan: unify report headers

Unify KASAN report header format for different kinds of bad memory accesses. Makes the code simpler. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/mm/kasan/repo

[PATCH v2 7/9] kasan: print page description after stacks

Moves page description after the stacks since it's less important. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/mm/kasan/report.c b/mm/kasan/report.c index 8dfb7a

[PATCH v2 0/9] kasan: improve error reports

fc fc ^ 88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc 88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc == Changes in v2: - split patch in multiple smaller ones - improve double-free reports

[PATCH v2 6/9] kasan: improve slab object description

[880068388540, 8800683885c0) Makes it more explanatory and adds information about relative offset of the accessed address to the start of the object. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 53 ++--- 1 file c

[PATCH v2 8/9] kasan: improve double-free report format

of the unexpected shadow value, print shadow bytes at the end of the report as in reports for other kinds of bugs. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/kasan.c | 3 ++- mm/kasan/kasan.h | 2 +- mm/kasan/report.c | 30 ++ 3 files chang

[PATCH v2 3/9] kasan: change allocation and freeing stack traces headers

Change stack traces headers from: Allocated: PID = 42 to: Allocated by task 42: Makes the report one line shorter and look better. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- mm/kasan/report.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --gi

[PATCH v2 1/9] kasan: introduce helper functions for determining bug type

Introduce get_shadow_bug_type() function, which determines bug type based on the shadow value for a particular kernel address. Introduce get_wild_bug_type() function, which determines bug type for addresses which don't have a corresponding shadow value. Signed-off-by: Andrey Konovalov <andr

Re: net/bridge: warning in br_fdb_find

On Mon, Feb 27, 2017 at 4:33 PM, Andrey Konovalov <andreyk...@google.com> wrote: > Hi, > > I'm getting a huge number of warning reports while fuzzing the kernel > with syzkaller. > Unfortunately they are not reproducible. > > On commit e5d56efc97f8240d0b5d66c0394938

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 8:59 PM, David Ahern wrote: > On 2/27/17 10:11 AM, Cong Wang wrote: >> The attached patch fixes this crash, but I am not sure if it is the >> best way to fix this bug yet... > > I'll take a look. I can not reproduce this using route or ip, so the

Re: net/ipv6: null-ptr-deref in ip6_route_del/lock_acquire

On Mon, Feb 27, 2017 at 9:34 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Feb 27, 2017 at 12:05 PM, Andrey Konovalov > <andreyk...@google.com> wrote: >> On Mon, Feb 27, 2017 at 8:59 PM, David Ahern <d...@cumulusnetworks.com> >> wrote: >

[PATCH] kcov: properly check if we are in an interrupt

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 from actual interrupts, do a proper check of whether we are really in an interrupt. Signed-off-by: Andrey Konovalov <andr

Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep

1533 [] SyS_connect+0x24/0x30 net/socket.c:1514 [] entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:209 ---[ end trace c7e036cf4dc54077 ]--- Thanks! On Sat, Oct 29, 2016 at 8:10 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Fri, Oct 28, 2016 at 5:40 PM, Andrey Konovalo

Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep

Hi Eric, Tested with both patches applied, still seeing the warning. Thanks! On Sat, Oct 29, 2016 at 7:43 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Sat, 2016-10-29 at 19:06 +0200, Andrey Konovalov wrote: >> Hi Cong, >> >> Tested with your patch, still get

Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep

wrote: > On Sat, 2016-10-29 at 19:59 +0200, Andrey Konovalov wrote: >> Hi Eric, >> >> Tested with both patches applied, still seeing the warning. >> >> Thanks! > > Arg, sorry, this was at the wrong place. > > Thanks for testing ! > > diff --git a/n

net/l2tp: use-after-free write in l2tp_ip6_close

Hi, I've got the following error report while running the syzkaller fuzzer: == BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr 8800677276d8 Write of size 8 by task a.out/8668 CPU: 0 PID: 8668 Comm: a.out Not

net/sctp: null-ptr-deref in sctp_inet_listen

Hi, I've got the following error report while running the syzkaller fuzzer: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Modules linked in: CPU: 1 PID: 3851 Comm: a.out Not tainted 4.9.0-rc4+

Re: net/sctp: null-ptr-deref in sctp_inet_listen

Hi Xin, Your patch seems to be fixing the issue. Tested-by: Andrey Konovalov <andreyk...@google.com> Thanks! On Tue, Nov 8, 2016 at 11:06 AM, Xin Long <lucien@gmail.com> wrote: > On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov <andreyk...@google.com> > wrot

[PATCH 1/2] stacktrace: fix print_stack_trace printing timestamp twice

+0x16/0x20 [ 18.822232] [ 18.822232] [] save_stack+0x46/0xd0 [ 18.822232] [ 18.822232] [] kasan_kmalloc+0xab/0xe0 Fix by calling printk only once. Signed-off-by: Andrey Konovalov <andreyk...@google.com> --- kernel/stacktrace.c | 6 -- 1 file changed, 4 insertions(+), 2 del

[PATCH 0/2] kasan,stacktrace: improve error reports

fc fc 00 00 fc fc fb fb fc fc 00 00 fc fc [ 24.247301] == Andrey Konovalov (2): stacktrace: fix print_stack_trace printing timestamp twice kasan: improve error reports kernel/stacktrace.c | 6 +- mm/kasan/report.c

[PATCH 2/2] kasan: improve error reports

1. Change header format. 2. Unify header format between different kinds of bad accesses. 3. Add empty lines between parts of the report to improve readability. 4. Improve slab object description. 5. Improve mm/kasan/report.c readability. Signed-off-by: Andrey Konovalov <andreyk...@google.

Re: net/l2tp: use-after-free write in l2tp_ip6_close

Hi Cong, Tried with your patch, still seeing the reports. Thanks! On Tue, Nov 8, 2016 at 12:02 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Nov 7, 2016 at 2:35 PM, Andrey Konovalov <andreyk...@google.com> > wrote: >> Hi, >> >> I've got the

Re: net/sctp: null-ptr-deref in sctp_inet_listen

On Wed, Nov 9, 2016 at 4:32 AM, Xin Long wrote: > this fix may break TYPE_SCTP_PRIMITIVE_SHUTDOWN statetable, > could you give the following one a try ? thanks. This one also works. Thanks. > > --- a/net/sctp/socket.c > +++ b/net/sctp/socket.c > @@ -4288,9 +4288,9 @@

net/tcp: warning in tcp_recvmsg

Hi, I've got the following error report while running the syzkaller fuzzer: [ cut here ] WARNING: CPU: 1 PID: 9957 at net/ipv4/tcp.c:1766 tcp_recvmsg+0x19d7/0x26e0 net/ipv4/tcp.c:1765 Modules linked in: CPU: 1 PID: 9957 Comm: syz-executor Not tainted 4.9.0-rc4+ #352

[PATCH v2] kcov: properly check if we are in an interrupt

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 from actual interrupts, do a proper check instead of just calling in_interrupt(). Signed-off-by: Andrey Konovalov <andr

Re: net/sctp: slab-out-of-bounds in sctp_sf_ootb

Hi Marcelo, I can confirm that your patch fixes the issue for me. Tested-by: Andrey Konovalov <andreyk...@google.com> On Mon, Oct 24, 2016 at 9:44 PM, Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> wrote: > Hi Andrey, > > On Mon, Oct 24, 2016 at 05:30:04PM +0200, A

Re: [PATCH] can: fix warning in bcm_connect/proc_register

Hi Oliver, I can confirm that your patch fixes the warnings for me. Tested-by: Andrey Konovalov <andreyk...@google.com> On Mon, Oct 24, 2016 at 10:17 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Oct 24, 2016 at 1:10 PM, Cong Wang <xiyou.wangc...@gmail.com> wro

net/dccp: warning in dccp_set_state

Hi, I've got the following error report while running the syzkaller fuzzer: WARNING: CPU: 1 PID: 21072 at net/dccp/proto.c:83 dccp_set_state+0x229/0x290 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 21072 Comm: syz-executor Not tainted 4.9.0-rc1+ #293 Hardware name: QEMU

Re: net/dccp: warning in dccp_set_state

Hi Eric, I can confirm that with your patch the warning goes away. Tested-by: Andrey Konovalov <andreyk...@google.com> On Mon, Oct 24, 2016 at 2:52 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Mon, 2016-10-24 at 05:47 -0700, Eric Dumazet wrote: >> On Mon, 2016

Fwd: net/ipx: null-ptr-deref in ipxrtr_route_packet

+a...@redhat.com Hi, I've got the following error report while running the syzkaller fuzzer: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Modules linked in: CPU: 0 PID: 3953 Comm: syz-executor

net/sctp: slab-out-of-bounds in sctp_sf_ootb

Hi, I've got the following error report while running the syzkaller fuzzer: == BUG: KASAN: slab-out-of-bounds in sctp_sf_ootb+0x634/0x6c0 at addr 88006bc1f210 Read of size 2 by task syz-executor/13493 CPU: 3 PID: 13493 Comm:

net/ipv4: warning in inet_sock_destruct

Hi, I've got the following error report while running the syzkaller fuzzer: [ cut here ] WARNING: CPU: 1 PID: 0 at net/ipv4/af_inet.c:153[] inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:153 Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted

Re: net/can: warning in bcm_connect/proc_register

xfffd, 0x0, "341b3a01b257849ca1d7d1ff9f999d8127b185f88d1d775dbec88a3aa6a8ddacdf2bdc324ea6578a21b85114610186c3817c34b05eaffd2c3f54f57fa81ba0", 0x1ff}, 0x60) Unfortunately I wasn't able to create a simpler reproducer. Thanks! On Mon, Oct 24, 2016 at 6:58 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Mon, Oct 24, 2016 at 9:21 AM, Andrey Konovalov <andreyk...@google.com> >

net/can: warning in bcm_connect/proc_register

Hi, I've got the following error report while running the syzkaller fuzzer: WARNING: CPU: 0 PID: 32451 at fs/proc/generic.c:345 proc_register+0x25e/0x300 proc_dir_entry 'can-bcm/249757' already registered Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 32451 Comm: syz-executor Not

net/netlink: null-ptr-deref in netlink_dump/lock_acquire

Hi, I've got the following error report while running the syzkaller fuzzer: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Modules linked in: CPU: 1 PID: 3933 Comm: syz-executor Not tainted

net/ipx: null-ptr-deref in ipxrtr_route_packet

Hi, I've got the following error report while running the syzkaller fuzzer: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN Modules linked in: CPU: 0 PID: 3953 Comm: syz-executor Not tainted

net/sctp: use-after-free in __sctp_connect

Hi, I've got the following error report while running the syzkaller fuzzer: == BUG: KASAN: use-after-free in __sctp_connect+0xabe/0xbf0 at addr 88006b1dc610 Read of size 4 by task syz-executor/21837 CPU: 2 PID: 21837 Comm:

net/udp: bug in skb_pull_rcsum

Hi, I've got the following error report while fuzzing the kernel with syzkaller. A reproducer is attached. On commit 9c763584b7c8911106bb77af7e648bef09af9d80 (4.9-rc6, Nov 20). [ cut here ] kernel BUG at net/core/skbuff.c:3029! invalid opcode: [#1] SMP KASAN

net/icmp: null-ptr-deref in icmp6_send

Hi, I've got the following error report while fuzzing the kernel with syzkaller. It seems that skb_dst(skb) may end up being NULL. As far as I can see the bug was introduced in commit 5d41ce29e ("net: icmp6_send should use dst dev to determine L3 domain"). ICMP v4 probaly has similar issue due

Re: net/can: use-after-free in bcm_rx_thr_flush

On Tue, Nov 22, 2016 at 6:29 PM, Oliver Hartkopp <socket...@hartkopp.net> wrote: > Hi Andrey, > > thanks for the report. > > Although I can't see the issue in the code ... > > On 11/22/2016 10:22

net/dccp: use-after-free in dccp_invalid_packet

Hi! I've got the following error report while running the syzkaller fuzzer. On commit d8e435f3ab6fea2ea324dce72b51dd7761747523 (Nov 26). dh->dccph_doff is being accessed (line 731) right after skb was freed (line 732) in net/dccp/ipv4.c. A reproducer is attached.

  1   2   3   4   5   6   7   8   9   10   >