Re: kernel BUG at drivers/dma-buf/dma-buf.c:LINE!
On Sat, Dec 19, 2020 at 3:50 AM syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit e722a295cf493388dae474745d30e91e1a2ec549 > Author: Greg Kroah-Hartman > Date: Thu Aug 27 12:36:27 2020 + > > staging: ion: remove from the tree > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17d4f13750 > start commit: abb3438d Merge tag 'm68knommu-for-v5.9-rc3' of git://git.k.. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 > dashboard link: https://syzkaller.appspot.com/bug?extid=d6734079f30f7fc39021 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1742859690 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: staging: ion: remove from the tree > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection The reproducer opens /dev/ion #syz fix: staging: ion: remove from the tree ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: BUG: unable to handle kernel paging request in ion_heap_clear_pages
On Sat, Nov 30, 2019 at 8:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:419593da Add linux-next specific files for 20191129 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12bfd882e0 > kernel config: https://syzkaller.appspot.com/x/.config?x=7c04b0959e75c206 > dashboard link: https://syzkaller.appspot.com/bug?extid=be6ccf3081ce8afd1b56 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+be6ccf3081ce8afd1...@syzkaller.appspotmail.com +Daniel, kasan-dev This is presumably from the new CONFIG_KASAN_VMALLOC and should be: #syz fix: kasan: support vmalloc backing of vm_map_ram() > BUG: unable to handle page fault for address: f52002e0 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 21ffee067 P4D 21ffee067 PUD aa11c067 PMD 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 3644 Comm: ion_system_heap Not tainted > 5.4.0-next-20191129-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] > RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 > Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e > 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 > ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 > RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212 > RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229 > RDX: 0001 RSI: b000 RDI: c9001700 > RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600 > R10: f52002e015ff R11: c9001700afff R12: f52002e0 > R13: b000 R14: R15: c9000c9f7d08 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: f52002e0 CR3: 778bd000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > memset+0x24/0x40 mm/kasan/common.c:107 > memset include/linux/string.h:410 [inline] > ion_heap_clear_pages+0x49/0x70 drivers/staging/android/ion/ion_heap.c:106 > ion_heap_sglist_zero+0x245/0x270 drivers/staging/android/ion/ion_heap.c:130 > ion_heap_buffer_zero+0xf5/0x150 drivers/staging/android/ion/ion_heap.c:145 > ion_system_heap_free+0x1eb/0x250 > drivers/staging/android/ion/ion_system_heap.c:163 > ion_buffer_destroy+0x159/0x2d0 drivers/staging/android/ion/ion.c:93 > ion_heap_deferred_free+0x29d/0x630 > drivers/staging/android/ion/ion_heap.c:239 > kthread+0x361/0x430 kernel/kthread.c:255 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > Modules linked in: > CR2: f52002e0 > ---[ end trace ee5c63907f1d6f00 ]--- > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] > RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 > Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e > 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 > ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 > RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212 > RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229 > RDX: 0001 RSI: b000 RDI: c9001700 > RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600 > R10: f52002e015ff R11: c9001700afff R12: f52002e0 > R13: b000 R14: R15: c9000c9f7d08 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: f52002e0 CR3: 778bd000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from
Re: binder stress testing
On Fri, May 17, 2019 at 8:34 PM Todd Kjos wrote: > > On Fri, May 17, 2019 at 5:51 PM Dmitry Vyukov wrote: > > > > > > > > > > > > From: Dmitry Vyukov > > > > > > Date: Fri, May 17, 2019 at 3:26 AM > > > > > > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen, > > > > > > Joel Fernandes, Christian Brauner, open list:ANDROID DRIVERS, LKML > > > > > > Cc: syzkaller > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I have 2 questions re drivers/android/binder.c stress testing. > > > > > > > > > > > > > > 1. Are there any docs on the kernel interface? Or some examples > > > > > > > on how > > > > > > > to use it and reference syscall sequences to make it do something > > > > > > > meaningful? > > > > > > > I hopefully figured out struct layouts and offsets of objects > > > > > > > thing, > > > > > > > but I still can't figure out handles, pointers, nodes, pointer to > > > > > > > nodes... pointer to data (?), references, cookies and where does > > > > > > > one > > > > > > > get valid values for these. > > > > > > > > > > > > The kernel interface is not well documented since it isn't intended > > > > > > to > > > > > > be used apart from libbinder. The best example for your purposes is > > > > > > probably the binderDriverInterfaceTest which you can find at > > > > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder/tests/binderDriverInterfaceTest.cpp. > > > > > > > > > > > > The libbinder source is at > > > > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder. > > > > > > > > > > > > > > > > > > > > 2. In my tests any transaction breaks binder device until the > > > > > > > next reboot. > > > > > > > If I open binder device twice, mmap, set context and then the > > > > > > > process > > > > > > > dies, then everything it released fine, in particular the context > > > > > > > (context_mgr_node gone). So the device is ready for a next test: > > > > > > > > > > > > > > [ 40.247970][ T6239] binder: binder_open: 6238:6239 > > > > > > > [ 40.250819][ T6239] binder: 6238:6239 node 1 u > > > > > > > c created > > > > > > > [ 40.253365][ T6239] binder: binder_mmap: 6238 > > > > > > > 200a-200a2000 (8 > > > > > > > K) vma f9 pagep 8025 > > > > > > > [ 40.256454][ T6239] binder: binder_open: 6238:6239 > > > > > > > [ 40.259604][ T6239] binder: binder_mmap: 6238 > > > > > > > 200c-200c2000 (8 > > > > > > > K) vma f9 pagep 8025 > > > > > > > [ 40.271526][ T6238] binder: 6238 close vm area > > > > > > > 200a-200a2000 (8 > > > > > > > K) vma 180200d9 pagep 8025 > > > > > > > [ 40.273113][ T6238] binder: 6238 close vm area > > > > > > > 200c-200c2000 (8 > > > > > > > K) vma 180200d9 pagep 8025 > > > > > > > [ 40.275058][ T17] binder: binder_flush: 6238 woke 0 threads > > > > > > > [ 40.275997][ T17] binder: binder_flush: 6238 woke 0 threads > > > > > > > [ 40.276968][ T17] binder: binder_deferred_release: 6238 > > > > > > > threads > > > > > > > 0, nodes 0 (ref 0), refs 0, active transactions 0 > > > > > > > [ 40.278626][ T17] binder: binder_deferred_release: 6238 > > > > > > > context_mgr_node gone > > > > > > > [ 40.279756][ T17] binder: binder_deferred_release: 6238 > > > > > > > threads > > > > > > > 1, nodes 1 (ref 0), refs 0, active transactions 0 > > > > > > > > > > > > > > > > > > > > > However, if I also send a transaction between these fd's, then > > > > > > > c
Re: binder stress testing
On Fri, May 17, 2019 at 5:51 PM Dmitry Vyukov wrote: > > > > > > > > From: Dmitry Vyukov > > > > Date: Fri, May 17, 2019 at 3:26 AM > > > > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen, > > > > Joel Fernandes, Christian Brauner, open list:ANDROID DRIVERS, LKML > > > > Cc: syzkaller > > > > > > > > > Hi, > > > > > > > > > > I have 2 questions re drivers/android/binder.c stress testing. > > > > > > > > > > 1. Are there any docs on the kernel interface? Or some examples on how > > > > > to use it and reference syscall sequences to make it do something > > > > > meaningful? > > > > > I hopefully figured out struct layouts and offsets of objects thing, > > > > > but I still can't figure out handles, pointers, nodes, pointer to > > > > > nodes... pointer to data (?), references, cookies and where does one > > > > > get valid values for these. > > > > > > > > The kernel interface is not well documented since it isn't intended to > > > > be used apart from libbinder. The best example for your purposes is > > > > probably the binderDriverInterfaceTest which you can find at > > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder/tests/binderDriverInterfaceTest.cpp. > > > > > > > > The libbinder source is at > > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder. > > > > > > > > > > > > > > 2. In my tests any transaction breaks binder device until the next > > > > > reboot. > > > > > If I open binder device twice, mmap, set context and then the process > > > > > dies, then everything it released fine, in particular the context > > > > > (context_mgr_node gone). So the device is ready for a next test: > > > > > > > > > > [ 40.247970][ T6239] binder: binder_open: 6238:6239 > > > > > [ 40.250819][ T6239] binder: 6238:6239 node 1 u > > > > > c created > > > > > [ 40.253365][ T6239] binder: binder_mmap: 6238 200a-200a2000 (8 > > > > > K) vma f9 pagep 8025 > > > > > [ 40.256454][ T6239] binder: binder_open: 6238:6239 > > > > > [ 40.259604][ T6239] binder: binder_mmap: 6238 200c-200c2000 (8 > > > > > K) vma f9 pagep 8025 > > > > > [ 40.271526][ T6238] binder: 6238 close vm area 200a-200a2000 (8 > > > > > K) vma 180200d9 pagep 8025 > > > > > [ 40.273113][ T6238] binder: 6238 close vm area 200c-200c2000 (8 > > > > > K) vma 180200d9 pagep 8025 > > > > > [ 40.275058][ T17] binder: binder_flush: 6238 woke 0 threads > > > > > [ 40.275997][ T17] binder: binder_flush: 6238 woke 0 threads > > > > > [ 40.276968][ T17] binder: binder_deferred_release: 6238 threads > > > > > 0, nodes 0 (ref 0), refs 0, active transactions 0 > > > > > [ 40.278626][ T17] binder: binder_deferred_release: 6238 > > > > > context_mgr_node gone > > > > > [ 40.279756][ T17] binder: binder_deferred_release: 6238 threads > > > > > 1, nodes 1 (ref 0), refs 0, active transactions 0 > > > > > > > > > > > > > > > However, if I also send a transaction between these fd's, then > > > > > context_mgr_node is not released: > > > > > > > > > > [ 783.851403][ T6167] binder: binder_open: 6166:6167 > > > > > [ 783.858801][ T6167] binder: 6166:6167 node 1 u > > > > > c created > > > > > [ 783.862458][ T6167] binder: binder_mmap: 6166 200a-200a2000 (8 > > > > > K) vma f9 pagep 8025 > > > > > [ 783.865777][ T6167] binder: binder_open: 6166:6167 > > > > > [ 783.867892][ T6167] binder: binder_mmap: 6166 200c-200c2000 (8 > > > > > K) vma f9 pagep 8025 > > > > > [ 783.870810][ T6167] binder: 6166:6167 write 76 at 2180, > > > > > read 0 at 2300 > > > > > [ 783.872211][ T6167] binder: 6166:6167 BC_TRANSACTION 2 -> 6166 - > > > > > node 1, data 2200-22c0 size 88-24-16 > > > > > [ 783.873819][ T
Re: binder stress testing
On Fri, May 17, 2019 at 5:45 PM Dmitry Vyukov wrote: > > On Fri, May 17, 2019 at 5:44 PM Dmitry Vyukov wrote: > > > > On Fri, May 17, 2019 at 5:36 PM Todd Kjos wrote: > > > > > > From: Dmitry Vyukov > > > Date: Fri, May 17, 2019 at 3:26 AM > > > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen, > > > Joel Fernandes, Christian Brauner, open list:ANDROID DRIVERS, LKML > > > Cc: syzkaller > > > > > > > Hi, > > > > > > > > I have 2 questions re drivers/android/binder.c stress testing. > > > > > > > > 1. Are there any docs on the kernel interface? Or some examples on how > > > > to use it and reference syscall sequences to make it do something > > > > meaningful? > > > > I hopefully figured out struct layouts and offsets of objects thing, > > > > but I still can't figure out handles, pointers, nodes, pointer to > > > > nodes... pointer to data (?), references, cookies and where does one > > > > get valid values for these. > > > > > > The kernel interface is not well documented since it isn't intended to > > > be used apart from libbinder. The best example for your purposes is > > > probably the binderDriverInterfaceTest which you can find at > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder/tests/binderDriverInterfaceTest.cpp. > > > > > > The libbinder source is at > > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder. > > > > > > > > > > > 2. In my tests any transaction breaks binder device until the next > > > > reboot. > > > > If I open binder device twice, mmap, set context and then the process > > > > dies, then everything it released fine, in particular the context > > > > (context_mgr_node gone). So the device is ready for a next test: > > > > > > > > [ 40.247970][ T6239] binder: binder_open: 6238:6239 > > > > [ 40.250819][ T6239] binder: 6238:6239 node 1 u > > > > c created > > > > [ 40.253365][ T6239] binder: binder_mmap: 6238 200a-200a2000 (8 > > > > K) vma f9 pagep 8025 > > > > [ 40.256454][ T6239] binder: binder_open: 6238:6239 > > > > [ 40.259604][ T6239] binder: binder_mmap: 6238 200c-200c2000 (8 > > > > K) vma f9 pagep 8025 > > > > [ 40.271526][ T6238] binder: 6238 close vm area 200a-200a2000 (8 > > > > K) vma 180200d9 pagep 8025 > > > > [ 40.273113][ T6238] binder: 6238 close vm area 200c-200c2000 (8 > > > > K) vma 180200d9 pagep 8025 > > > > [ 40.275058][ T17] binder: binder_flush: 6238 woke 0 threads > > > > [ 40.275997][ T17] binder: binder_flush: 6238 woke 0 threads > > > > [ 40.276968][ T17] binder: binder_deferred_release: 6238 threads > > > > 0, nodes 0 (ref 0), refs 0, active transactions 0 > > > > [ 40.278626][ T17] binder: binder_deferred_release: 6238 > > > > context_mgr_node gone > > > > [ 40.279756][ T17] binder: binder_deferred_release: 6238 threads > > > > 1, nodes 1 (ref 0), refs 0, active transactions 0 > > > > > > > > > > > > However, if I also send a transaction between these fd's, then > > > > context_mgr_node is not released: > > > > > > > > [ 783.851403][ T6167] binder: binder_open: 6166:6167 > > > > [ 783.858801][ T6167] binder: 6166:6167 node 1 u > > > > c created > > > > [ 783.862458][ T6167] binder: binder_mmap: 6166 200a-200a2000 (8 > > > > K) vma f9 pagep 8025 > > > > [ 783.865777][ T6167] binder: binder_open: 6166:6167 > > > > [ 783.867892][ T6167] binder: binder_mmap: 6166 200c-200c2000 (8 > > > > K) vma f9 pagep 8025 > > > > [ 783.870810][ T6167] binder: 6166:6167 write 76 at 2180, > > > > read 0 at 2300 > > > > [ 783.872211][ T6167] binder: 6166:6167 BC_TRANSACTION 2 -> 6166 - > > > > node 1, data 2200-22c0 size 88-24-16 > > > > [ 783.873819][ T6167] binder: 6166:6167 node 3 u > > > > c created > > > > [ 783.875032][ T6167] binder: 6166 new ref 4 desc 1 for node 3 > > > > [ 783.875860][ T6167] binder
Re: binder stress testing
On Fri, May 17, 2019 at 5:44 PM Dmitry Vyukov wrote: > > On Fri, May 17, 2019 at 5:36 PM Todd Kjos wrote: > > > > From: Dmitry Vyukov > > Date: Fri, May 17, 2019 at 3:26 AM > > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen, > > Joel Fernandes, Christian Brauner, open list:ANDROID DRIVERS, LKML > > Cc: syzkaller > > > > > Hi, > > > > > > I have 2 questions re drivers/android/binder.c stress testing. > > > > > > 1. Are there any docs on the kernel interface? Or some examples on how > > > to use it and reference syscall sequences to make it do something > > > meaningful? > > > I hopefully figured out struct layouts and offsets of objects thing, > > > but I still can't figure out handles, pointers, nodes, pointer to > > > nodes... pointer to data (?), references, cookies and where does one > > > get valid values for these. > > > > The kernel interface is not well documented since it isn't intended to > > be used apart from libbinder. The best example for your purposes is > > probably the binderDriverInterfaceTest which you can find at > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder/tests/binderDriverInterfaceTest.cpp. > > > > The libbinder source is at > > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder. > > > > > > > > 2. In my tests any transaction breaks binder device until the next reboot. > > > If I open binder device twice, mmap, set context and then the process > > > dies, then everything it released fine, in particular the context > > > (context_mgr_node gone). So the device is ready for a next test: > > > > > > [ 40.247970][ T6239] binder: binder_open: 6238:6239 > > > [ 40.250819][ T6239] binder: 6238:6239 node 1 u > > > c created > > > [ 40.253365][ T6239] binder: binder_mmap: 6238 200a-200a2000 (8 > > > K) vma f9 pagep 8025 > > > [ 40.256454][ T6239] binder: binder_open: 6238:6239 > > > [ 40.259604][ T6239] binder: binder_mmap: 6238 200c-200c2000 (8 > > > K) vma f9 pagep 8025 > > > [ 40.271526][ T6238] binder: 6238 close vm area 200a-200a2000 (8 > > > K) vma 180200d9 pagep 8025 > > > [ 40.273113][ T6238] binder: 6238 close vm area 200c-200c2000 (8 > > > K) vma 180200d9 pagep 8025 > > > [ 40.275058][ T17] binder: binder_flush: 6238 woke 0 threads > > > [ 40.275997][ T17] binder: binder_flush: 6238 woke 0 threads > > > [ 40.276968][ T17] binder: binder_deferred_release: 6238 threads > > > 0, nodes 0 (ref 0), refs 0, active transactions 0 > > > [ 40.278626][ T17] binder: binder_deferred_release: 6238 > > > context_mgr_node gone > > > [ 40.279756][ T17] binder: binder_deferred_release: 6238 threads > > > 1, nodes 1 (ref 0), refs 0, active transactions 0 > > > > > > > > > However, if I also send a transaction between these fd's, then > > > context_mgr_node is not released: > > > > > > [ 783.851403][ T6167] binder: binder_open: 6166:6167 > > > [ 783.858801][ T6167] binder: 6166:6167 node 1 u > > > c created > > > [ 783.862458][ T6167] binder: binder_mmap: 6166 200a-200a2000 (8 > > > K) vma f9 pagep 8025 > > > [ 783.865777][ T6167] binder: binder_open: 6166:6167 > > > [ 783.867892][ T6167] binder: binder_mmap: 6166 200c-200c2000 (8 > > > K) vma f9 pagep 8025 > > > [ 783.870810][ T6167] binder: 6166:6167 write 76 at 2180, > > > read 0 at 2300 > > > [ 783.872211][ T6167] binder: 6166:6167 BC_TRANSACTION 2 -> 6166 - > > > node 1, data 2200-22c0 size 88-24-16 > > > [ 783.873819][ T6167] binder: 6166:6167 node 3 u > > > c created > > > [ 783.875032][ T6167] binder: 6166 new ref 4 desc 1 for node 3 > > > [ 783.875860][ T6167] binder: node 3 u -> ref 4 > > > desc 1 > > > [ 783.876868][ T6167] binder: 6166:6167 wrote 76 of 76, read return 0 of > > > 0 > > > [ 783.886714][ T6167] binder: 6166 close vm area 200a-200a2000 (8 > > > K) vma 180200d9 pagep 8025 > > > [ 783.888161][ T6167] binder: 6166 close vm area 200c-200c2000 (8 > > > K) vma 180200d9 pagep 8025 > >
Re: binder stress testing
On Fri, May 17, 2019 at 5:36 PM Todd Kjos wrote: > > From: Dmitry Vyukov > Date: Fri, May 17, 2019 at 3:26 AM > To: Greg Kroah-Hartman, Arve Hjønnevåg, Todd Kjos, Martijn Coenen, > Joel Fernandes, Christian Brauner, open list:ANDROID DRIVERS, LKML > Cc: syzkaller > > > Hi, > > > > I have 2 questions re drivers/android/binder.c stress testing. > > > > 1. Are there any docs on the kernel interface? Or some examples on how > > to use it and reference syscall sequences to make it do something > > meaningful? > > I hopefully figured out struct layouts and offsets of objects thing, > > but I still can't figure out handles, pointers, nodes, pointer to > > nodes... pointer to data (?), references, cookies and where does one > > get valid values for these. > > The kernel interface is not well documented since it isn't intended to > be used apart from libbinder. The best example for your purposes is > probably the binderDriverInterfaceTest which you can find at > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder/tests/binderDriverInterfaceTest.cpp. > > The libbinder source is at > https://android.googlesource.com/platform/frameworks/native/+/refs/heads/master/libs/binder. > > > > > 2. In my tests any transaction breaks binder device until the next reboot. > > If I open binder device twice, mmap, set context and then the process > > dies, then everything it released fine, in particular the context > > (context_mgr_node gone). So the device is ready for a next test: > > > > [ 40.247970][ T6239] binder: binder_open: 6238:6239 > > [ 40.250819][ T6239] binder: 6238:6239 node 1 u > > c created > > [ 40.253365][ T6239] binder: binder_mmap: 6238 200a-200a2000 (8 > > K) vma f9 pagep 8025 > > [ 40.256454][ T6239] binder: binder_open: 6238:6239 > > [ 40.259604][ T6239] binder: binder_mmap: 6238 200c-200c2000 (8 > > K) vma f9 pagep 8025 > > [ 40.271526][ T6238] binder: 6238 close vm area 200a-200a2000 (8 > > K) vma 180200d9 pagep 8025 > > [ 40.273113][ T6238] binder: 6238 close vm area 200c-200c2000 (8 > > K) vma 180200d9 pagep 8025 > > [ 40.275058][ T17] binder: binder_flush: 6238 woke 0 threads > > [ 40.275997][ T17] binder: binder_flush: 6238 woke 0 threads > > [ 40.276968][ T17] binder: binder_deferred_release: 6238 threads > > 0, nodes 0 (ref 0), refs 0, active transactions 0 > > [ 40.278626][ T17] binder: binder_deferred_release: 6238 > > context_mgr_node gone > > [ 40.279756][ T17] binder: binder_deferred_release: 6238 threads > > 1, nodes 1 (ref 0), refs 0, active transactions 0 > > > > > > However, if I also send a transaction between these fd's, then > > context_mgr_node is not released: > > > > [ 783.851403][ T6167] binder: binder_open: 6166:6167 > > [ 783.858801][ T6167] binder: 6166:6167 node 1 u > > c created > > [ 783.862458][ T6167] binder: binder_mmap: 6166 200a-200a2000 (8 > > K) vma f9 pagep 8025 > > [ 783.865777][ T6167] binder: binder_open: 6166:6167 > > [ 783.867892][ T6167] binder: binder_mmap: 6166 200c-200c2000 (8 > > K) vma f9 pagep 8025 > > [ 783.870810][ T6167] binder: 6166:6167 write 76 at 2180, > > read 0 at 2300 > > [ 783.872211][ T6167] binder: 6166:6167 BC_TRANSACTION 2 -> 6166 - > > node 1, data 2200-22c0 size 88-24-16 > > [ 783.873819][ T6167] binder: 6166:6167 node 3 u > > c created > > [ 783.875032][ T6167] binder: 6166 new ref 4 desc 1 for node 3 > > [ 783.875860][ T6167] binder: node 3 u -> ref 4 > > desc 1 > > [ 783.876868][ T6167] binder: 6166:6167 wrote 76 of 76, read return 0 of 0 > > [ 783.886714][ T6167] binder: 6166 close vm area 200a-200a2000 (8 > > K) vma 180200d9 pagep 8025 > > [ 783.888161][ T6167] binder: 6166 close vm area 200c-200c2000 (8 > > K) vma 180200d9 pagep 8025 > > [ 783.890134][ T27] binder: binder_flush: 6166 woke 0 threads > > [ 783.891036][ T27] binder: binder_flush: 6166 woke 0 threads > > [ 783.892027][ T2903] binder: release 6166:6167 transaction 2 out, still > > active > > [ 783.893097][ T2903] binder: unexpected work type, 4, not freed > > [ 783.893947][ T2903] binder: undelivered TRANSACTION_COMPLETE > > [ 783.894849][ T2903] binder: node 3 now dead, refs 1, death 0 > > [ 7
Re: kernel BUG at drivers/android/binder_alloc.c:LINE! (3)
On Fri, May 17, 2019 at 5:26 PM Todd Kjos wrote: > > Yes (and syzbot seemed to confirm the fix). I didn't realize I needed > to manually close the issue. I guess you closed it yesterday. This is required to auto-close the bug when the commit is merged: > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+f9f3f388440283da2...@syzkaller.appspotmail.com Otherwise somebody needs to say: #syz fix: binder: fix BUG_ON found by selinux-testsuite > From: Dmitry Vyukov > Date: Fri, May 17, 2019 at 3:08 AM > To: syzbot > Cc: Arve Hjønnevåg, Christian Brauner, open list:ANDROID DRIVERS, Greg > Kroah-Hartman, Joel Fernandes, LKML, Martijn Coenen, syzkaller-bugs, > Todd Kjos , Todd Kjos > > > On Fri, Mar 29, 2019 at 10:55 AM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot has tested the proposed patch and the reproducer did not trigger > > > crash: > > > > > > Reported-and-tested-by: > > > syzbot+f9f3f388440283da2...@syzkaller.appspotmail.com > > > > > > Tested on: > > > > > > commit: 8c2ffd91 Linux 5.1-rc2 > > > git tree: > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > > master > > > kernel config: https://syzkaller.appspot.com/x/.config?x=8dcdce25ea72bedf > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > patch: > > > https://syzkaller.appspot.com/x/patch.diff?x=10fed66320 > > > > > > Note: testing is done by a robot and is best-effort only. > > > > > > Todd, > > > > Should this patch fix the bug? Should we close the bug as fixed then? > > In my local testing I see this BUG still fires, but if we will leave > > old fixed bugs open, we will not get notifications about new crashes. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: possible deadlock in vfs_fallocate
On Wed, May 9, 2018 at 6:57 PM 'Todd Kjos' via syzkaller-bugs
wrote:
>
> +Joel Fernandes
>
> On Wed, May 9, 2018 at 12:55 AM Eric Biggers wrote:
>>
>> [+ashmem maintainers]
>>
>> On Sun, Apr 29, 2018 at 10:00:03AM -0700, syzbot wrote:
>> > Hello,
>> >
>> > syzbot hit the following crash on upstream commit
>> > cdface5209349930ae1b51338763c8e029971b97 (Sun Apr 29 03:07:21 2018 +)
>> > Merge tag 'for_linus_stable' of
>> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
>> > syzbot dashboard link:
>> > https://syzkaller.appspot.com/bug?extid=148c2885d71194f18d28
>> >
>> > C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5054004375584768
>> > syzkaller reproducer:
>> > https://syzkaller.appspot.com/x/repro.syz?id=6438048191479808
>> > Raw console output:
>> > https://syzkaller.appspot.com/x/log.txt?id=5404215203594240
>> > Kernel config:
>> > https://syzkaller.appspot.com/x/.config?id=7043958930931867332
>> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Let's test Tetsuo's patch
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+148c2885d71194f18...@syzkaller.appspotmail.com
>> > It will help syzbot understand when the bug is fixed. See footer for
>> > details.
>> > If you forward the report, please keep this part and the footer.
>> >
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> > random: sshd: uninitialized urandom read (32 bytes read)
>> >
>> > ==
>> > WARNING: possible circular locking dependency detected
>> > 4.17.0-rc2+ #23 Not tainted
>> > --
>> > syz-executor715/4492 is trying to acquire lock:
>> > (ptrval) (sb_writers#6){.+.+}, at: file_start_write
>> > include/linux/fs.h:2718 [inline]
>> > (ptrval) (sb_writers#6){.+.+}, at: vfs_fallocate+0x5be/0x8d0
>> > fs/open.c:318
>> >
>> > but task is already holding lock:
>> > (ptrval) (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xac/0x560
>> > drivers/staging/android/ashmem.c:440
>> >
>> > which lock already depends on the new lock.
>> >
>> >
>> > the existing dependency chain (in reverse order) is:
>> >
>> > -> #3 (ashmem_mutex){+.+.}:
>> >__mutex_lock_common kernel/locking/mutex.c:756 [inline]
>> >__mutex_lock+0x16d/0x17f0 kernel/locking/mutex.c:893
>> >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
>> >ashmem_mmap+0x53/0x460 drivers/staging/android/ashmem.c:361
>> >call_mmap include/linux/fs.h:1789 [inline]
>> >mmap_region+0xd13/0x1820 mm/mmap.c:1723
>> >do_mmap+0xc79/0x11d0 mm/mmap.c:1494
>> >do_mmap_pgoff include/linux/mm.h:2237 [inline]
>> >vm_mmap_pgoff+0x1fb/0x2a0 mm/util.c:357
>> >ksys_mmap_pgoff+0x4c9/0x640 mm/mmap.c:1544
>> >__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>> >__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
>> >__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
>> >do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> >
>> > -> #2 (&mm->mmap_sem){}:
>> >__might_fault+0x155/0x1e0 mm/memory.c:4555
>> >_copy_to_user+0x30/0x110 lib/usercopy.c:25
>> >copy_to_user include/linux/uaccess.h:155 [inline]
>> >filldir+0x1ea/0x3a0 fs/readdir.c:196
>> >dir_emit_dot include/linux/fs.h:3378 [inline]
>> >dir_emit_dots include/linux/fs.h:3389 [inline]
>> >dcache_readdir+0x13a/0x620 fs/libfs.c:192
>> >iterate_dir+0x4b0/0x5d0 fs/readdir.c:51
>> >__do_sys_getdents fs/readdir.c:231 [inline]
>> >__se_sys_getdents fs/readdir.c:212 [inline]
>> >__x64_sys_getdents+0x293/0x4e0 fs/readdir.c:212
>> >do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> >
>> > -> #1 (&sb->s_type->i_mutex_key#11){}:
>> >down_write+0x87/0x120 kernel/locking/rwsem.c:70
>> >inode_lock include/linux/fs.h:713 [inline]
>> >do_last fs/namei.c:3274 [inline]
>> >path_openat+0x123b/0x4e20 fs/namei.c:3501
>> >do_filp_open+0x249/0x350 fs/namei.c:3535
>> >do_sys_open+0x56f/0x740 fs/open.c:1093
>> >__do_sys_open fs/open.c: [inline]
>> >__se_sys_open fs/open.c:1106 [inline]
>> >__x64_sys_open+0x7e/0xc0 fs/open.c:1106
>> >do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> >
>> > -> #0 (sb_writers#6){.+.+}:
>> >lock_acquire+0x1dc/0x520 kernel/locking/lockdep.c:3920
>> >percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36
>> > [inline]
>> >percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
>>
Re: KASAN: use-after-free Read in binder_release_work
On Mon, Apr 23, 2018 at 11:18 AM, Martijn Coenen wrote:
> On Thu, Apr 19, 2018 at 11:35 PM, Eric Biggers wrote:
>> Martijn, this is going to be fixed by
>> https://patchwork.kernel.org/patch/10312345/
>> ("ANDROID: binder: prevent transactions into own process"), right?
>> The syzbot bug ID in that patch is for a bug that is already closed,
>> so if it's not too late you should use this one.
>
> Yeah that should fix it. Why was it closed? I think the syzbot bug ID
> I used in that patch was from the original report to LKML. Greg
> mentioned the patch was already in his queue.
Hi Martijn,
In short: too many bugs in kernel + long turnaround time for fixes.
Originally it was detected as "KASAN: use-after-free Read in
__list_del_entry_valid (3)":
https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d
and that happened in binder. But then syzkaller found a reproducer for
it, but it turned out to be in rdma subsystem. It's generally not
possible to properly distinguish different bugs that look similar, and
if syzbot does more sensitive bug classification, then it will also
inevitably report more duplicates. So that bug was closed as an rdma
bug.
Now syzbot already skips list_del frame and takes the next one, so it
should become slightly better.
Let's close this one with the binder fix (since that one was closed
with an rdma fix):
#syz fix: ANDROID: binder: prevent transactions into own process.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: WARNING in __vm_enough_memory
On Tue, Jan 16, 2018 at 12:58 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 8418f88764046d0e8ca6a3c04a69a0e57189aa1e
> 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 attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
Most likely it is drivers/staging/android/ashmem.c which is guilty. So
+ashmem maintainers.
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1515720420.441:8): avc: denied { sys_admin } for
> pid=3511 comm="syzkaller485245" capability=21
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> audit: type=1400 audit(1515720420.495:9): avc: denied { sys_chroot } for
> pid=3512 comm="syzkaller485245" capability=18
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> [ cut here ]
> memory commitment underflow
> WARNING: CPU: 0 PID: 3512 at mm/util.c:606 __vm_enough_memory+0x5a6/0x810
> mm/util.c:604
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 0 PID: 3512 Comm: syzkaller485245 Not tainted 4.15.0-rc7-next-20180111+
> #94
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> panic+0x1e4/0x41c kernel/panic.c:183
> __warn+0x1dc/0x200 kernel/panic.c:547
> report_bug+0x211/0x2d0 lib/bug.c:184
> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1102
> RIP: 0010:__vm_enough_memory+0x5a6/0x810 mm/util.c:604
> RSP: 0018:8801bfbaf8e0 EFLAGS: 00010282
> RAX: dc08 RBX: 110037f75f21 RCX: 815a613e
> RDX: RSI: 110037e84d3b RDI: 0293
> RBP: 8801bfbafa90 R08: 110037f75eaf R09:
> R10: R11: R12: 8801bfbafa68
> R13: 869b8c80 R14: 0fff R15: dc00
> security_vm_enough_memory_mm+0x90/0xb0 security/security.c:327
> mmap_region+0x321/0x15a0 mm/mmap.c:1666
> do_mmap+0x73c/0xf70 mm/mmap.c:1494
> do_mmap_pgoff include/linux/mm.h:2224 [inline]
> vm_mmap_pgoff+0x1de/0x280 mm/util.c:333
> SYSC_mmap_pgoff mm/mmap.c:1544 [inline]
> SyS_mmap_pgoff+0x23b/0x5f0 mm/mmap.c:1502
> SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x440ac9
> RSP: 002b:007dff58 EFLAGS: 0212 ORIG_RAX: 0009
> RAX: ffda RBX: RCX: 00440ac9
> RDX: 0003 RSI: 00fff000 RDI: 2000
> RBP: 7fff R08: R09:
> R10: 0032 R11: 0212 R12: 6873612f7665642f
> R13: 6c616b7a79732f2e R14: R15:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> 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 report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a1144593661efb50562d9624f%40google
