Re: [PATCH 0/2] [RFC] Volatile ranges (v4)

John Stultz john.stultz at linaro.org writes: Ok. So here's another iteration of the fadvise volatile range code. I realize this is still a way off from being ready, but I wanted to post what I have to share with folks working on the various range/interval management ideas as well as update

Re: Potential use-after-free in ____call_usermodehelper

On Wed, Aug 21, 2013 at 8:35 PM, Dmitry Vyukov dvyu...@google.com 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-overflow errors

Potential use-after-free in ____call_usermodehelper

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

Re: Out-of-bounds access in get_wchan (arch/x86/kernel/process_64.c)

On Wed, Sep 11, 2013 at 2:06 AM, Andi Kleen a...@linux.intel.com wrote: Indeed, get_wchan ensures that fpstack+THREAD_SIZE, but then dereferences fp+8: 434 if (fp (unsigned long)stack || 435 fp = (unsigned long)stack+THREAD_SIZE) 436

Re: [PATCH] fs: make sure we do not read beyond allocation

On Fri, Oct 4, 2013 at 12:57 AM, Al Viro v...@zeniv.linux.org.uk 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

Re: [PATCH] fs: make sure we do not read beyond allocation

On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger richard.weinber...@gmail.com 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: a)

Potential use-after-free in SyS_remap_file_pages

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

Re: [PATCH] fs: make sure we do not read beyond allocation

On Fri, Oct 11, 2013 at 3:26 PM, Dmitry Vyukov dvyu...@google.com wrote: On Fri, Oct 4, 2013 at 5:53 PM, Richard Weinberger rich...@nod.at wrote: Am 04.10.2013 12:53, schrieb Dmitry Vyukov: On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger richard.weinber...@gmail.com wrote: ... [1] yes

Re: [PATCH] fs: make sure we do not read beyond allocation

On Fri, Oct 4, 2013 at 5:53 PM, Richard Weinberger rich...@nod.at wrote: Am 04.10.2013 12:53, schrieb Dmitry Vyukov: On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger richard.weinber...@gmail.com wrote: ... [1] yes, yes, I know - the mere mention of security should've prevented

Re: Potential use-after-free in ____call_usermodehelper

] Shadow gap:fe On Fri, Aug 23, 2013 at 7:48 PM, Dmitry Vyukov dvyu...@google.com wrote: On Wed, Aug 21, 2013 at 8:35 PM, Dmitry Vyukov dvyu...@google.com wrote: Hi, I'm working on a memory error detector AddressSanitizer for Linux kernel (https://code.google.com/p/address

Out-of-bounds access in get_wchan (arch/x86/kernel/process_64.c)

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:

Re: Potential use-after-free in ____call_usermodehelper

On Wed, Sep 4, 2013 at 12:27 AM, Dan Aloni alo...@stratoscale.com 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

Re: [PATCH] Out-of-bounds access in get_wchan (arch/x86/kernel/process_64.c)

On Fri, Sep 13, 2013 at 3:03 AM, Wolfram Gloger wm...@dent.med.uni-muenchen.de wrote: H. Peter Anvin h...@zytor.com 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

Re: [PATCH] Out-of-bounds access in get_wchan (arch/x86/kernel/process_64.c)

On Fri, Sep 13, 2013 at 3:03 AM, Wolfram Gloger wm...@dent.med.uni-muenchen.de wrote: H. Peter Anvin h...@zytor.com 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

Re: perf/events/core: Potential race in list_del_event

ping On Wed, Jun 18, 2014 at 5:07 PM, Alexey Preobrazhensky pre...@google.com wrote: Hi, I’m working on AddressSanitizer[1] -- a tool that detects use-after-free and out-of-bounds bugs in kernel. We’ve encountered a heap-use-after-free in list_del_event() in linux kernel 3.15+ (revision

Re: [RFC/PATCH RESEND -next 20/21] fs: dcache: manually unpoison dname after allocation to shut up kasan's reports

beyound allocated size. If it read a little beyond allocated size, IMHO, it is better to allocate correct size. kmalloc(name-len + 1, GFP_KERNEL); -- kmalloc(roundup(name-len + 1, sizeof(unsigned long ), GFP_KERNEL); Isn't it? I absolutely agree! Thanks. Reported-by: Dmitry Vyukov dvyu

Re: [RFC/PATCH RESEND -next 20/21] fs: dcache: manually unpoison dname after allocation to shut up kasan's reports

On Tue, Jul 15, 2014 at 1:34 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 07/15/14 10:12, Joonsoo Kim wrote: On Wed, Jul 09, 2014 at 03:30:14PM +0400, Andrey Ryabinin wrote: We need to manually unpoison rounded up allocation size for dname to avoid kasan's reports in __d_lookup_rcu.

Re: drivers: random: Shift out-of-bounds in _mix_pool_bytes

On Fri, Oct 24, 2014 at 7:04 PM, Sasha Levin sasha.le...@oracle.com wrote: On 10/24/2014 09:42 AM, Peter Zijlstra wrote: On Fri, Oct 24, 2014 at 09:23:35AM -0400, Sasha Levin wrote: i 32 may happen to be i, but is there anything that prevents the compiler from returning, let's say, 42?

Re: [PATCH RFC] x86_64: per-cpu memory for user-space

On Sat, Sep 13, 2014 at 7:35 AM, Konstantin Khlebnikov koc...@gmail.com wrote: This patch implements user-space per-cpu memory in the same manner as in kernel-space: each cpu has its own %gs base address. On x86_64 %fs is used for thread local storage, %gs usually is free. User-space

Re: [PATCH RFC] x86_64: per-cpu memory for user-space

On Sun, Sep 14, 2014 at 7:06 AM, Andi Kleen a...@linux.intel.com wrote: On Sat, Sep 13, 2014 at 06:35:34PM +0400, Konstantin Khlebnikov wrote: This patch implements user-space per-cpu memory in the same manner as in kernel-space: each cpu has its own %gs base address. On x86_64 %fs is used for

Re: [RFC PATCH v4 13/13] kasan: introduce inline instrumentation

On Mon, Oct 6, 2014 at 7:54 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: This patch only demonstration how easy this could be achieved. GCC doesn't support this feature yet. Two patches required for this: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00452.html

Re: [PATCH v4 02/13] efi: libstub: disable KASAN for efistub

looks good to me On Mon, Oct 6, 2014 at 7:53 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: KASan as many other options should be disabled for this stub to prevent build failures. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com --- drivers/firmware/efi/libstub/Makefile | 1 + 1

Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak

On Wed, Oct 1, 2014 at 3:45 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 10/01/2014 02:39 PM, Catalin Marinas wrote: On Mon, Sep 29, 2014 at 03:10:01PM +0100, Dmitry Vyukov wrote: On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04

Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak

On Wed, Oct 1, 2014 at 6:11 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools usually don't play well together. For example, due to asan quarantine lots of leaks

Re: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.

On Thu, Nov 20, 2014 at 12:03 PM, Ingo Molnar mi...@kernel.org wrote: * Andrey Ryabinin ryabinin@gmail.com wrote: I've counted 16: aab515d (fib_trie: remove potential out of bound access) 984f173 ([SCSI] sd: Fix potential out-of-bounds access) 5e9ae2e (aio: fix use-after-free in

Re: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.

On Fri, Nov 21, 2014 at 2:00 AM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 20 Nov 2014 20:32:30 +0400 Dmitry Vyukov dvyu...@google.com wrote: Let me provide some background first. Well that was useful. Andrey, please slurp Dmitry's info into the 0/n changelog? Also, some

Re: [PATCH v3 08/13] mm: slub: introduce metadata_access_enable()/metadata_access_disable()

Looks good to me. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: Wrap access to object's metadata in external functions with metadata_access_enable()/metadata_access_disable() function calls. This hooks separates payload accesses from metadata accesses which

Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support for slub allocator

On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: With this patch kasan will be able to catch bugs in memory allocated by slub. Initially all objects in newly allocated slab page, marked as free. Later, when allocation of slub object happens, requested by caller

Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support for slub allocator

On Fri, Sep 26, 2014 at 12:25 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 09/26/2014 08:48 AM, Dmitry Vyukov wrote: On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -6,6 +6,7 @@ if HAVE_ARCH_KASAN

Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support for slub allocator

On Fri, Sep 26, 2014 at 7:22 AM, Christoph Lameter c...@linux.com wrote: On Thu, 25 Sep 2014, Dmitry Vyukov wrote: + depends on SLUB_DEBUG What does SLUB_DEBUG do? I think that generally we don't want any other *heavy* debug checks to be required for kasan. SLUB_DEBUG includes

Re: [PATCH v3 00/13] Kernel address sanitizer - runtime memory debugger.

On Fri, Sep 26, 2014 at 10:01 AM, Sasha Levin sasha.le...@oracle.com wrote: On 09/24/2014 08:43 AM, Andrey Ryabinin wrote: Hi. This is a third iteration of kerenel address sanitizer (KASan). KASan is a runtime memory debugger designed to find use-after-free and out-of-bounds bugs.

Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak

Looks good to me. We can disable kasan instrumentation of this file as well. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: kmalloc internally round up allocation size, and kmemleak uses rounded up size as object's size. This makes kasan to complain while

Re: [PATCH v3 12/13] lib: add kasan test module

Looks good to me. On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: This is a test module doing varios nasty things like out of bounds accesses, use after free. It is usefull for testing kernel debugging features like kernel address sanitizer. It mostly

Re: [RFC PATCH v3 13/13] kasan: introduce inline instrumentation

On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: This patch only demonstration how easy this could be achieved. GCC doesn't support this feature yet. Two patches required for this: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00452.html

Re: [PATCH v3 00/13] Kernel address sanitizer - runtime memory debugger.

On Fri, Sep 26, 2014 at 10:22 AM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:07 GMT+04:00 Dmitry Vyukov dvyu...@google.com: On Fri, Sep 26, 2014 at 10:01 AM, Sasha Levin sasha.le...@oracle.com wrote: On 09/24/2014 08:43 AM, Andrey Ryabinin wrote: Hi. This is a third

Re: [PATCH v3 11/13] kmemleak: disable kasan instrumentation for kmemleak

On Fri, Sep 26, 2014 at 9:36 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:10 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Looks good to me. We can disable kasan instrumentation of this file as well. Yes, but why? I don't think we need that. Just gut feeling. Such tools

Re: [PATCH v3 00/13] Kernel address sanitizer - runtime memory debugger.

On Fri, Sep 26, 2014 at 10:48 PM, Yuri Gribov tetra2...@gmail.com wrote: On Fri, Sep 26, 2014 at 9:29 PM, Dmitry Vyukov dvyu...@google.com wrote: So in kernel we will need to support all API versions, and the following looks like a much simpler way to identify current API version

Re: [RFC PATCH v3 13/13] kasan: introduce inline instrumentation

On Wed, Sep 24, 2014 at 4:44 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: This patch only demonstration how easy this could be achieved. GCC doesn't support this feature yet. Two patches required for this: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00452.html

Re: [RFC PATCH v3 13/13] kasan: introduce inline instrumentation

On Fri, Sep 26, 2014 at 9:33 PM, Andrey Ryabinin ryabinin@gmail.com wrote: 2014-09-26 21:18 GMT+04:00 Dmitry Vyukov dvyu...@google.com: Yikes! So this works during bootstrap, for user memory accesses, valloc memory, etc, right? Yes, this works. Userspace memory access in instrumented

Re: [PATCH v3 00/13] Kernel address sanitizer - runtime memory debugger.

OK, great, then we can do __SANITIZE_ADDRESS_ABI__ On Mon, Sep 29, 2014 at 6:36 PM, Peter Zijlstra pet...@infradead.org wrote: On Mon, Sep 29, 2014 at 06:22:46PM +0400, Dmitry Vyukov wrote: But on the second though... what do we want to do with pre-build modules? Can you envision that somebody

Re: [PATCH v3 05/13] mm: page_alloc: add kasan hooks on alloc and free paths

On Wed, Sep 24, 2014 at 5:44 AM, Andrey Ryabinin a.ryabi...@samsung.com wrote: Add kernel address sanitizer hooks to mark allocated page's addresses as accessible in corresponding shadow region. Mark freed pages as inaccessible. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com ---

Out-of-bounds access in nfnetlink_bind

Hi, I am working on Kernel AddressSanitizer, a fast memory error detector for kernel: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel Here is an error report that I got while running trinity: == BUG:

Out-of-bounds access in __do_proc_doulongvec_minmax

Hi, I am working on AddressSanitizer, a fast memory error detector for kernel: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel Here is a bug report that I've got while running trinity: == BUG:

Re: Out-of-bounds access in __do_proc_doulongvec_minmax

On Wed, Dec 3, 2014 at 3:39 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 12/03/2014 12:04 PM, Dmitry Vyukov wrote: Hi, I am working on AddressSanitizer, a fast memory error detector for kernel: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel Here is a bug

Re: Out-of-bounds access in __do_proc_doulongvec_minmax

On Wed, Dec 3, 2014 at 4:37 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 12/03/2014 04:27 PM, Dmitry Vyukov wrote: On Wed, Dec 3, 2014 at 3:39 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 12/03/2014 12:04 PM, Dmitry Vyukov wrote: Hi, I am working on AddressSanitizer, a fast

Out-of-bounds write in driver_override_show

Hello, I am working on Kernel AddressSanitizer, a fast memory error detector for kernel: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel Here is an error report that I got while running trinity: BUG: AddressSanitizer: out of bounds access in vsnprintf+0xd0/0x890 at

Re: Out-of-bounds write in driver_override_show

On Mon, Dec 1, 2014 at 10:12 PM, Alex Williamson alex.william...@redhat.com wrote: On Sat, 2014-11-29 at 10:05 -0800, Greg Kroah-Hartman wrote: On Sat, Nov 29, 2014 at 01:38:10PM +0400, Dmitry Vyukov wrote: Hello, I am working on Kernel AddressSanitizer, a fast memory error detector

Re: [PATCH v11 19/19] kasan: enable instrumentation of global variables

Can a module be freed in an interrupt? On Mon, Feb 16, 2015 at 5:44 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote: On 02/16/2015 05:58 AM, Rusty Russell wrote: Andrey Ryabinin a.ryabi...@samsung.com writes: This feature let us to detect accesses out of bounds of global variables. This

Re: [RFC] slub memory quarantine

Please hold on with this. Dmitry Chernenkov is working on a quarantine that works with both slub and slab, does not cause spurious OOMs and does not depend on slub-debug which has unacceptable performance (acquires global lock). Me or Dmitry C will send an email to kasan-...@googlegroups.com to

Re: GPF in shm_lock ipc

>> through ltp. Also adding Manfred to the Cc, who always catches my idiotic >> mistakes. >> >> 8<- >> From: Davidlohr Bueso <d...@stgolabs.net> >> Date: Mon, 12 Oct 2015 19:38:34 -0700

deadlock between tty_write and tty_send_xchar

Hello, I've hit the following deadlock while running syzkaller on commit ce5c2d2c256a4c8b523036537cd6be2d6af8f69d (Nov 7): [ INFO: possible circular locking dependency detected ] 4.3.0+ #57 Not tainted --- syzkaller_execu/24882 is trying to

Re: deadlock between tty_write and tty_send_xchar

On Wed, Nov 11, 2015 at 1:05 PM, Peter Hurley <pe...@hurleysoftware.com> wrote: > On 11/11/2015 03:35 AM, Dmitry Vyukov wrote: >> Hello, >> >> I've hit the following deadlock while running syzkaller on commit >> ce5c2d2c256a4c8b523036537cd6be2d6af8f69d (Nov 7)

WARNING in shmem_evict_inode

Hello, The following program: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include #include #define SYS_memfd_create 319 long fd; void *thr(void *p) { syscall(SYS_ftruncate, fd, 0x8ul, 0, 0, 0, 0); return 0; } int main() {

Re: WARNING in task_participate_group_stop

On Mon, Nov 2, 2015 at 4:13 PM, Oleg Nesterov <o...@redhat.com> wrote: > Hi Dmitry, > > On 11/02, Dmitry Vyukov wrote: >> >> WARNING: CPU: 1 PID: 1 at kernel/signal.c:334 >> task_participate_group_stop+0x157/0x1d0() >> Modules linked in: >> C

WARNING in task_participate_group_stop

Hello, I've hit the following WARNING on 6a13feb9c82803e2b815eca72fa7a9f5561d7861 (4.3) [ cut here ] WARNING: CPU: 1 PID: 1 at kernel/signal.c:334 task_participate_group_stop+0x157/0x1d0() Modules linked in: CPU: 1 PID: 1 Comm: init Not tainted 4.3.0 #48 Hardware name:

Re: Resource leak in unshare

On Mon, Nov 2, 2015 at 8:01 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Dmitry Vyukov <dvyu...@google.com> writes: > >> Hello, >> >> I am hitting the following warnings on >> bcee19f424a0d8c26ecf2607b73c690802658b29 (4.3): > &g

Re: Resource leak in unshare

On Tue, Nov 3, 2015 at 1:48 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Tue, 2015-11-03 at 09:48 +0100, Dmitry Vyukov wrote: >> On Mon, Nov 2, 2015 at 8:01 PM, Eric W. Biederman <ebied...@xmission.com> >> wrote: >> > Dmitry Vyukov <dvyu.

Re: [PATCH v2 0/2] UBSan: run-time undefined behavior sanity checker

I guess just nobody reviewed this. I would like to see this merged as well. On Tue, Nov 3, 2015 at 6:20 PM, Sasha Levin wrote: > Anyone knows why wasn't this merged a year ago? I didn't see any review > comments, and it > ended up finding real bugs. > > On 11/14/2014

Re: [PATCH v2 0/2] UBSan: run-time undefined behavior sanity checker

+Andrey On Tue, Nov 3, 2015 at 6:35 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > I guess just nobody reviewed this. I would like to see this merged as well. > > > > On Tue, Nov 3, 2015 at 6:20 PM, Sasha Levin <sasha.le...@oracle.com> wrote: >> Anyone knows why

Use-after-free in selinux_ip_postroute_compat

Hello, I've updated from bcee19f424a0d8c26ecf2607b73c690802658b29 (Sep 21) to 8e483ed1342a4ea45b70f0f33ac54eff7a33d918 (Nov 4) and start seeing the following use-after-free reports: BUG: KASan: use after free in selinux_ip_postroute_compat+0x2af/0x2d0 at addr 88003dbdc148 Read of size 8 by

Re: Use-after-free in ipv4_conntrack_defrag

+netdev, lkml Adding public lists as requested. Below is a use-after-free report in ipv4_conntrack_defrag and a fix from Eric. On Thu, Nov 5, 2015 at 7:57 PM, Eric Dumazet <eduma...@google.com> wrote: > On Thu, Nov 5, 2015 at 10:33 AM, Dmitry Vyukov <dvyu...@google.com>

Re: [GIT PULL] locking changes for v4.4

On Wed, Nov 4, 2015 at 5:16 AM, Paul E. McKenney wrote: > On Tue, Nov 03, 2015 at 05:30:29PM -0800, Linus Torvalds wrote: >> On Tue, Nov 3, 2015 at 3:58 PM, Linus Torvalds >> wrote: >> > >> > I think I'll pull this, but then just make a

Re: [GIT PULL] locking changes for v4.4

On Wed, Nov 4, 2015 at 5:01 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Nov 04, 2015 at 03:51:01PM +0100, Dmitry Vyukov wrote: >> To clarify, yes, documentation and tooling was my main motivation. > > Right; I don't object to having _ctrl() methods pur

Re: [lkp] [fs] df4c0e36f1: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]

Hi Ying, Does testing happen with CONFIG_KASAN=y? If not, this is probably a flake caused by something else. On Mon, Nov 2, 2015 at 9:06 AM, kernel test robot wrote: > FYI, we noticed the below changes on > >

Resource leak in unshare

Hello, I am hitting the following warnings on bcee19f424a0d8c26ecf2607b73c690802658b29 (4.3): [ cut here ] WARNING: CPU: 3 PID: 16049 at fs/proc/generic.c:575 remove_proc_entry+0x284/0x2f0() remove_proc_entry: removing non-empty directory 'net/dev_snmp6', leaking at least

Re: Use-after-free in ep_remove_wait_queue

On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: >> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote: >> >>> Probably the issue discussed

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

Thanx, Paul > >> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> >> Cc: Alexander Potapenko <gli...@google.com> >> Cc: Andrew Morton <a...@linux-foundation.org> >> Cc: Andrey Konovalov <andreyk...@google.com> &g

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:01 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Wed, Oct 14, 2015 at 05:50:34PM +0200, Dmitry Vyukov wrote: >> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney >> <paul...@linux.vnet.ibm.com> wrote: >> > On Wed, Oct 1

Re: GPF in keyring_destroy

On Mon, Oct 19, 2015 at 12:33 PM, David Howells <dhowe...@redhat.com> wrote: > Dmitry Vyukov <dvyu...@google.com> wrote: > >> > Does the attached patch fix it for you? >> >> Yes, it fixes the crash for me. > > I have an additional patch to prevent key

Re: GPF in keyring_destroy

eate_on_node+0x1c2/0x1c2 > [] ret_from_fork+0x3f/0x70 > [] ? kthread_create_on_node+0x1c2/0x1c2 > > Note the value in RAX. This is a 32-bit representation of -ENOKEY. > > The solution is to only call ->destroy() if the key was successfully > insta

Re: GPF in keyring_destroy

On Mon, Oct 19, 2015 at 11:30 AM, David Howells <dhowe...@redhat.com> wrote: > Dmitry Vyukov <dvyu...@google.com> wrote: > >> > Does the attached patch fix it for you? >> >> Yes, it fixes the crash for me. > > Can I put you down as a Tested-by? >

Re: [PATCH] fs: fix data races on inode->i_flctx

I would expect that you see something else. The issue that I fixed would fire very infrequently and unreproducibly. On Mon, Oct 19, 2015 at 5:18 PM, William Dauchy wrote: > Hello Dmitry, > > On Mon, Sep 21, 2015 at 1:44 PM, Jeff Layton wrote: >> Ok,

Re: some problems about kasan

On Thu, Oct 15, 2015 at 8:59 AM, zhong jiang wrote: > 1、 I feel confused about one of the cases when testing the cases kasan can > solve . the function come from the kernel in the /lib/test_kasan.c. > > static noinline void __init kmalloc_uaf2(void) > { > char

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:16 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Oct 14, 2015 at 06:08:16PM +0200, Dmitry Vyukov wrote: >> >> > So I add READ_ONCE_NOCHECK() for accesses for which the compiler cannot >> >> > prove safe address for KA

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:20 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Oct 14, 2015 at 06:18:58PM +0200, Dmitry Vyukov wrote: >> >> Well, if another thread writes it byte-by-byte, it pretty much does >> not matter how you read it. >> Note

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:19 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > > > On 10/14/2015 06:50 PM, Dmitry Vyukov wrote: >> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney >> <paul...@linux.vnet.ibm.com> wrote: >>> On Wed, Oct 14, 2015 at 08:

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 7:04 PM, Paul E. McKenney wrote: >> >> >> > On Wed, Oct 14, 2015 at 08:28:43AM -0700, tip-bot for Andrey >> >> >> > Ryabinin wrote: >> >> >> >> Commit-ID: 4115ffdf4d6f8986a7abe1dd522c163f599bc0e6 >> >> >> >> Gitweb: >> >> >> >>

Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:20 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Wed, Oct 14, 2015 at 06:08:16PM +0200, Dmitry Vyukov wrote: >> On Wed, Oct 14, 2015 at 6:01 PM, Paul E. McKenney >> <paul...@linux.vnet.ibm.com> wrote: >> > On Wed, Oct

Re: Unkillable processes due to PTRACE_TRACEME

On Mon, Oct 19, 2015 at 9:49 PM, Oleg Nesterov <o...@redhat.com> wrote: > On 10/19, Dmitry Vyukov wrote: >> >> The following program hangs in some interesting state and is not >> killable (started by a normal user, not root): > > Thanks. > >> #incl

Unkillable processes due to PTRACE_TRACEME

Hello, The following program hangs in some interesting state and is not killable (started by a normal user, not root): // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include #include #include void *thr(void *arg) { ptrace(PTRACE_TRACEME, 0,

Re: Unkillable processes due to PTRACE_TRACEME

On Mon, Oct 19, 2015 at 10:17 PM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Oct 19, 2015 at 9:49 PM, Oleg Nesterov <o...@redhat.com> wrote: >> On 10/19, Dmitry Vyukov wrote: >>> >>> The following program hangs in some interesting state and is not

Re: Unkillable processes due to PTRACE_TRACEME

On Tue, Oct 20, 2015 at 10:34 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Oct 19, 2015 at 10:17 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Mon, Oct 19, 2015 at 9:49 PM, Oleg Nesterov <o...@redhat.com> wrote: >>> On 10/19, Dmitry Vyukov wr

GPF in shm_lock ipc

Hello, The following program crashes kernel: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include int main() { long r0 = syscall(SYS_shmget, 0x0ul, 0x2ul, 0x8ul); long r1 = syscall(SYS_shmat, r0, 0x2000ul, 0x0ul); long r2 =

Uninterruptable hang in sendfile

Hello, The following program leads to hang in D state in: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include int main() { long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);

GPF in keyring_destroy

Hello, The following program crashes kernel: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include int main() { long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul); long r1 = syscall(SYS_mmap,

Use-after-free in ep_remove_wait_queue

Hello, The following program causes use-after-in kernel: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include int main() { long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul); long r1 =

Infinite loop in ip6_fragment

Hello, The following program causes infinite loop in ip6_fragment function: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include int main() { long r0 = syscall(SYS_socket, 0xaul, 0x3ul, 0x53cul); long r1 = syscall(SYS_mmap,

GPF in rt6_uncached_list_flush_dev

Hello, The following program causes episodic crashes: // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #define CLONE_NEWNET 0x4000 int main(void) { unshare(CLONE_NEWNET); } On commit dd36d7393d6310b0c1adefb22fba79c3cf8a577c

Re: GPF in shm_lock ipc

On Mon, Oct 12, 2015 at 1:41 PM, Vlastimil Babka <vba...@suse.cz> wrote: > On 10/12/2015 11:55 AM, Dmitry Vyukov wrote: >> >> Hello, >> >> The following program crashes kernel: >> >> // autogenerated by syzkaller (http://github.com/google/syzkaller) >

Re: Use-after-free in ep_remove_wait_queue

On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote: > On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote: > >> Probably the issue discussed in >> >> http://thread.gmane.org/gmane.linux.kernel/2057497/ >> >> and previous related threads. >> > > Same issue, but

Re: [PATCH v2 2/2] x86/process: Silence KASAN warnings in get_wchan()

On Tue, Oct 13, 2015 at 3:48 PM, Ingo Molnar wrote: > > * Andrey Ryabinin wrote: > >> get_wchan() is racy by design, it may access volatile stack >> of running task, thus it may access redzone in a stack frame >> and cause KASAN to warn about this. >>

Potential data race in flush_to_ldisc

Hello, We are working on a dynamic data race detector for the Linux kernel, KernelThreadSanitizer (ktsan): https://github.com/google/ktsan/wiki While booting kernel (upstream revision 21bdb584af8c) we got a report: ThreadSanitizer: data-race in release_tty Write of size 8 by thread T325

Data races in generic_fillattr

We are working on a dynamic data race detector for the Linux kernel, KernelThreadSanitizer (ktsan): https://github.com/google/ktsan/wiki While booting kernel (upstream revision 21bdb584af8c) we get a bunch of reports of the form: ThreadSanitizer: data-race in generic_fillattr Read of size 8 by

Re: Potential data race in psmouse_interrupt

Hello, I am looking at this code in __ps2_command again: /* * The reset command takes a long time to execute. */ timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500); timeout = wait_event_timeout(ps2dev-wait, !(READ_ONCE(ps2dev-flags) PS2_FLAG_CMD1), timeout); if

Re: Potential data race in uart_ioctl

On Tue, Aug 25, 2015 at 10:58 PM, Peter Hurley pe...@hurleysoftware.com wrote: 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

Re: Potential data race in uart_ioctl

On Tue, Aug 25, 2015 at 8:26 PM, Peter Hurley pe...@hurleysoftware.com wrote: Hi Andrey, On 08/25/2015 08:17 AM, Andrey Konovalov wrote: Hi! We are working on a dynamic data race detector for the Linux kernel called KernelThreadSanitizer (ktsan) (https://github.com/google/ktsan/wiki).

Re: Potential data race in uart_ioctl

On Tue, Aug 25, 2015 at 8:32 PM, Dmitry Vyukov dvyu...@google.com wrote: On Tue, Aug 25, 2015 at 8:26 PM, Peter Hurley pe...@hurleysoftware.com wrote: Hi Andrey, On 08/25/2015 08:17 AM, Andrey Konovalov wrote: Hi! We are working on a dynamic data race detector for the Linux kernel called

Re: Potential data race in psmouse_interrupt

On Fri, Aug 28, 2015 at 8:32 PM, Dmitry Torokhov <dmitry.torok...@gmail.com> wrote: > On Fri, Aug 28, 2015 at 11:08 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Fri, Aug 28, 2015 at 7:51 PM, Dmitry Torokhov >> <dmitry.torok...@gmail.com> wrote: >>>

[PATCH] tty: fix data race in flush_to_ldisc

hutting down flush_to_ldisc work. Signed-off-by: Dmitry Vyukov <dvyu...@google.com> --- drivers/tty/tty_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 57fc6ee..0df24c1 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/t

Re: Data race in __inode_add_bytes

On Mon, Aug 31, 2015 at 9:35 PM, Andrey Konovalov wrote: > 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: > >

  1   2   3   4   5   6   7   8   9   10   >