Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

[Eric Biggers]

On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> > 
> > And I still don't really understand.  After this patchset, there is still 
> > code
> > nearly identical to the above (doing a temporary mapping just for a memcpy) 
> > that
> > would still be using kmap_atomic().
> 
> I don't understand.  You mean there would be other call sites calling:
> 
> kmap_atomic()
> memcpy()
> kunmap_atomic()

Yes, there are tons of places that do this.  Try 'git grep -A6 kmap_atomic'
and look for memcpy().

Hence why I'm asking what will be the "recommended" way to do this...
kunmap_thread() or kmap_atomic()?

> And since I don't know the call site details if there are kmap_thread() calls
> which are better off as kmap_atomic() calls I think it is worth converting
> them.  But I made the assumption that kmap users would already be calling
> kmap_atomic() if they could (because it is more efficient).

Not necessarily.  In cases where either one is correct, people might not have
put much thought into which of kmap() and kmap_atomic() they are using.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

[Eric Biggers]

On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > The kmap() calls in this FS are localized to a single thread.  To avoid
> > > the over head of global PKRS updates use the new kmap_thread() call.
> > >
> > > @@ -2410,12 +2410,12 @@ static inline struct page 
> > > *f2fs_pagecache_get_page(
> > >  
> > >  static inline void f2fs_copy_page(struct page *src, struct page *dst)
> > >  {
> > > - char *src_kaddr = kmap(src);
> > > - char *dst_kaddr = kmap(dst);
> > > + char *src_kaddr = kmap_thread(src);
> > > + char *dst_kaddr = kmap_thread(dst);
> > >  
> > >   memcpy(dst_kaddr, src_kaddr, PAGE_SIZE);
> > > - kunmap(dst);
> > > - kunmap(src);
> > > + kunmap_thread(dst);
> > > + kunmap_thread(src);
> > >  }
> > 
> > Wouldn't it make more sense to switch cases like this to kmap_atomic()?
> > The pages are only mapped to do a memcpy(), then they're immediately 
> > unmapped.
> 
> Maybe you missed the earlier thread from Thomas trying to do something
> similar for rather different reasons ...
> 
> https://lore.kernel.org/lkml/20200919091751.06...@linutronix.de/

I did miss it.  I'm not subscribed to any of the mailing lists it was sent to.

Anyway, it shouldn't matter.  Patchsets should be standalone, and not require
reading random prior threads on linux-kernel to understand.

And I still don't really understand.  After this patchset, there is still code
nearly identical to the above (doing a temporary mapping just for a memcpy) that
would still be using kmap_atomic().  Is the idea that later, such code will be
converted to use kmap_thread() instead?  If not, why use one over the other?

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

[Eric Biggers]

On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> The kmap() calls in this FS are localized to a single thread.  To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
> 
> Cc: Jaegeuk Kim 
> Cc: Chao Yu 
> Signed-off-by: Ira Weiny 
> ---
>  fs/f2fs/f2fs.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d9e52a7f3702..ff72a45a577e 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2410,12 +2410,12 @@ static inline struct page *f2fs_pagecache_get_page(
>  
>  static inline void f2fs_copy_page(struct page *src, struct page *dst)
>  {
> - char *src_kaddr = kmap(src);
> - char *dst_kaddr = kmap(dst);
> + char *src_kaddr = kmap_thread(src);
> + char *dst_kaddr = kmap_thread(dst);
>  
>   memcpy(dst_kaddr, src_kaddr, PAGE_SIZE);
> - kunmap(dst);
> - kunmap(src);
> + kunmap_thread(dst);
> + kunmap_thread(src);
>  }

Wouldn't it make more sense to switch cases like this to kmap_atomic()?
The pages are only mapped to do a memcpy(), then they're immediately unmapped.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] staging: android: ashmem: Fix lockdep warning for write operation

[Eric Biggers]

On Wed, Jul 15, 2020 at 07:45:27PM -0700, Suren Baghdasaryan wrote:
> syzbot report [1] describes a deadlock when write operation against an
> ashmem fd executed at the time when ashmem is shrinking its cache results
> in the following lock sequence:
> 
> Possible unsafe locking scenario:
> 
> CPU0CPU1
> 
>lock(fs_reclaim);
> lock(&sb->s_type->i_mutex_key#13);
> lock(fs_reclaim);
>lock(&sb->s_type->i_mutex_key#13);
> 
> kswapd takes fs_reclaim and then inode_lock while generic_perform_write
> takes inode_lock and then fs_reclaim. However ashmem does not support
> writing into backing shmem with a write syscall. The only way to change
> its content is to mmap it and operate on mapped memory. Therefore the race
> that lockdep is warning about is not valid. Resolve this by introducing a
> separate lockdep class for the backing shmem inodes.
> 
> [1]: https://lkml.kernel.org/lkml/0b5f9d059aa20...@google.com/
> 
> Signed-off-by: Suren Baghdasaryan 

Please add proper tags:

Reported-by: syzbot+7a0d9d0b26efefe61...@syzkaller.appspotmail.com
Fixes: ...
Cc: sta...@vger.kernel.org


The Reported-by tag to use was given in the original syzbot report.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: possible deadlock in shmem_fallocate (4)

[Eric Biggers]

On Tue, Jul 14, 2020 at 11:32:52AM +0800, Hillf Danton wrote:
> 
> Add FALLOC_FL_NOBLOCK and on the shmem side try to lock inode upon the
> new flag. And the overall upside is to keep the current gfp either in
> the khugepaged context or not.
> 
> --- a/include/uapi/linux/falloc.h
> +++ b/include/uapi/linux/falloc.h
> @@ -77,4 +77,6 @@
>   */
>  #define FALLOC_FL_UNSHARE_RANGE  0x40
>  
> +#define FALLOC_FL_NOBLOCK0x80
> +

You can't add a new UAPI flag to fix a kernel-internal problem like this.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 4/7] crypto: remove ARC4 support from the skcipher API

[Eric Biggers]

[+linux-wireless, Marcel Holtmann, and Denis Kenzior]

On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> a maintenance perspective, since it does not quite behave like other
> skciphers do in terms of key vs IV lifetime. Since we are leaving the
> library interface in place, which is used by the various WEP and TKIP
> implementations we have in the tree, we can safely drop this code now
> it no longer has any users.
> 
> Signed-off-by: Ard Biesheuvel 

Last year there was a discussion where it was mentioned that iwd uses
"ecb(arc4)" via AF_ALG.  So can we really remove it yet?
See https://lkml.kernel.org/r/97bb95f6-4a4c-4984-9eab-6069e19b4...@holtmann.org
Note that the code isn't in "iwd" itself but rather in "libell" which iwd
depends on: https://git.kernel.org/pub/scm/libs/ell/ell.git/

Apparently it also uses md4 and ecb(des) too.

Marcel and Denis, what's your deprecation plan for these obsolete and insecure
algorithms?

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

[Eric Biggers]

On Mon, Jun 15, 2020 at 09:57:16PM -0400, Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset() is currently used for the buffer clearing. However,
> it is entirely possible that the compiler may choose to optimize away the
> memory clearing especially if LTO is being used. To make sure that this
> optimization will not happen, memzero_explicit(), which is introduced
> in v3.18, is now used in kzfree() to do the clearing.
> 
> Fixes: 3ef0e5ba4673 ("slab: introduce kzfree()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Waiman Long 
> ---
>  mm/slab_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9e72ba224175..37d48a56431d 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1726,7 +1726,7 @@ void kzfree(const void *p)
>   if (unlikely(ZERO_OR_NULL_PTR(mem)))
>   return;
>   ks = ksize(mem);
> - memset(mem, 0, ks);
> + memzero_explicit(mem, ks);
>   kfree(mem);
>  }
>  EXPORT_SYMBOL(kzfree);

This is a good change, but the commit message isn't really accurate.  AFAIK, no
one has found any case where this memset() gets optimized out.  And even with
LTO, it would be virtually impossible due to all the synchronization and global
data structures that kfree() uses.  (Remember that this isn't the C standard
function "free()", so the compiler can't assign it any special meaning.)
Not to mention that LTO support isn't actually upstream yet.

I still agree with the change, but it might be helpful if the commit message
were honest that this is really a hardening measure and about properly conveying
the intent.  As-is this sounds like a critical fix, which might confuse people.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [ashmem] possible deadlock in shmem_fallocate (4)

[Eric Biggers]

ashmem is calling shmem_fallocate() during memory reclaim, which can deadlock on
inode_lock().  +Cc maintainers of drivers/staging/android/ashmem.c.

On Thu, Dec 26, 2019 at 01:25:09PM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:46cf053e Linux 5.5-rc3
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=162124aee0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
> dashboard link: https://syzkaller.appspot.com/bug?extid=7a0d9d0b26efefe61780
> 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+7a0d9d0b26efefe61...@syzkaller.appspotmail.com
> 
> ==
> WARNING: possible circular locking dependency detected
> 5.5.0-rc3-syzkaller #0 Not tainted
> --
> kswapd0/1852 is trying to acquire lock:
> 888098919cd8 (&sb->s_type->i_mutex_key#13){+.+.}, at: inode_lock
> include/linux/fs.h:791 [inline]
> 888098919cd8 (&sb->s_type->i_mutex_key#13){+.+.}, at:
> shmem_fallocate+0x15a/0xd40 mm/shmem.c:2735
> 
> but task is already holding lock:
> 89a41e00 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
> mm/page_alloc.c:4922
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (fs_reclaim){+.+.}:
>__fs_reclaim_acquire mm/page_alloc.c:4084 [inline]
>fs_reclaim_acquire.part.0+0x24/0x30 mm/page_alloc.c:4095
>fs_reclaim_acquire mm/page_alloc.c:4695 [inline]
>prepare_alloc_pages mm/page_alloc.c:4692 [inline]
>__alloc_pages_nodemask+0x52d/0x910 mm/page_alloc.c:4744
>alloc_pages_vma+0xdd/0x620 mm/mempolicy.c:2170
>shmem_alloc_page+0xc0/0x180 mm/shmem.c:1499
>shmem_alloc_and_acct_page+0x165/0x990 mm/shmem.c:1524
>shmem_getpage_gfp+0x56d/0x29a0 mm/shmem.c:1838
>shmem_getpage mm/shmem.c:154 [inline]
>shmem_write_begin+0x105/0x1e0 mm/shmem.c:2487
>generic_perform_write+0x23b/0x540 mm/filemap.c:3309
>__generic_file_write_iter+0x25e/0x630 mm/filemap.c:3438
>generic_file_write_iter+0x420/0x68e mm/filemap.c:3470
>call_write_iter include/linux/fs.h:1902 [inline]
>new_sync_write+0x4d3/0x770 fs/read_write.c:483
>__vfs_write+0xe1/0x110 fs/read_write.c:496
>vfs_write+0x268/0x5d0 fs/read_write.c:558
>ksys_write+0x14f/0x290 fs/read_write.c:611
>__do_sys_write fs/read_write.c:623 [inline]
>__se_sys_write fs/read_write.c:620 [inline]
>__x64_sys_write+0x73/0xb0 fs/read_write.c:620
>do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> -> #0 (&sb->s_type->i_mutex_key#13){+.+.}:
>check_prev_add kernel/locking/lockdep.c:2476 [inline]
>check_prevs_add kernel/locking/lockdep.c:2581 [inline]
>validate_chain kernel/locking/lockdep.c:2971 [inline]
>__lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3955
>lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485
>down_write+0x93/0x150 kernel/locking/rwsem.c:1534
>inode_lock include/linux/fs.h:791 [inline]
>shmem_fallocate+0x15a/0xd40 mm/shmem.c:2735
>ashmem_shrink_scan drivers/staging/android/ashmem.c:462 [inline]
>ashmem_shrink_scan+0x370/0x510 drivers/staging/android/ashmem.c:437
>do_shrink_slab+0x40f/0xad0 mm/vmscan.c:526
>shrink_slab mm/vmscan.c:687 [inline]
>shrink_slab+0x19a/0x680 mm/vmscan.c:660
>shrink_node_memcgs mm/vmscan.c:2687 [inline]
>shrink_node+0x46a/0x1ad0 mm/vmscan.c:2791
>kswapd_shrink_node mm/vmscan.c:3539 [inline]
>balance_pgdat+0x7c8/0x11f0 mm/vmscan.c:3697
>kswapd+0x5c3/0xf30 mm/vmscan.c:3948
>kthread+0x361/0x430 kernel/kthread.c:255
>ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> 
> other info that might help us debug this:
> 
>  Possible unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(fs_reclaim);
>lock(&sb->s_type->i_mutex_key#13);
>lock(fs_reclaim);
>   lock(&sb->s_type->i_mutex_key#13);
> 
>  *** DEADLOCK ***
> 
> 2 locks held by kswapd0/1852:
>  #0: 89a41e00 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
> mm/page_alloc.c:4922
>  #1: 89a1f948 (shrinker_rwsem){}, at: shrink_slab
> mm/vmscan.c:677 [inline]
>  #1: 89a1f948 (shrinker_rwsem){}, at: shrink_slab+0xe6/0x680
> mm/vmscan.c:660
> 
> stack backtrace:
> CPU: 0 PID: 1852 Comm: kswapd0 Not tainted 5.5.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>

Re: WARNING in bdev_read

[Eric Biggers]

On Thu, Oct 17, 2019 at 10:02:07AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:bc88f85c kthread: make __kthread_queue_delayed_work static
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14e25608e0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e0ac4d9b35046343
> dashboard link: https://syzkaller.appspot.com/bug?extid=787bcbef9b5fec61944b
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=159fd35360
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17e8217360
> 
> The bug was bisected to:
> 
> commit c48c9f7ff32b8b3965a08e40eb6763682d905b5d
> Author: Valdis Klētnieks 
> Date:   Wed Aug 28 16:08:17 2019 +
> 
> staging: exfat: add exfat filesystem code to staging

This bisection looks correct.

On a related topic: it seems the exfat filesystem is missing a mailing list.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] erofs: move erofs out of staging

[Eric Biggers]

On Sun, Aug 18, 2019 at 09:22:01AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 09:16:38AM -0700, Eric Biggers wrote:
> > Ted's observation was about maliciously-crafted filesystems, though, so
> > integrity-only features such as metadata checksums are irrelevant.  Also the
> > filesystem version is irrelevant; anything accepted by the kernel code 
> > (even if
> 
> I think allowing users to mount file systems (any of ours) without
> privilege is a rather bad idea.  But that doesn't mean we should not be
> as robust as we can.  Optionally disabling support for legacy formats
> at compile and/or runtime is something we should actively look into as
> well.
> 
> > it's legacy/deprecated) is open attack surface.
> > 
> > I personally consider it *mandatory* that we deal with this stuff.  But I 
> > can
> > understand that we don't do a good job at it, so we shouldn't hold a new
> > filesystem to an unfairly high standard relative to other filesystems...
> 
> I very much disagree.  We can't really force anyone to fix up old file
> systems.  But we can very much hold new ones to (slightly) higher
> standards.  Thats the only way to get the average quality up.  Some as
> for things like code style - we can't magically fix up all old stuff,
> but we can and usually do hold new code to higher standards.  (Often not
> to standards as high as I'd personally prefer, btw).

Not sure what you're even disagreeing with, as I *do* expect new filesystems to
be held to a high standard, and to be written with the assumption that the
on-disk data may be corrupted or malicious.  We just can't expect the bar to be
so high (e.g. no bugs) that it's never been attained by *any* filesystem even
after years/decades of active development.  If the developers were careful, the
code generally looks robust, and they are willing to address such bugs as they
are found, realistically that's as good as we can expect to get...

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] erofs: move erofs out of staging

[Eric Biggers]

On Sun, Aug 18, 2019 at 08:58:12AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 18, 2019 at 11:11:54AM -0400, Theodore Y. Ts'o wrote:
> > Note that of the mainstream file systems, ext4 and xfs don't guarantee
> > that it's safe to blindly take maliciously provided file systems, such
> > as those provided by a untrusted container, and mount it on a file
> > system without problems.  As I recall, one of the XFS developers
> > described file system fuzzing reports as a denial of service attack on
> > the developers.
> 
> I think this greatly misrepresents the general attitute of the XFS
> developers.  We take sanity checks for the modern v5 on disk format
> very series, and put a lot of effort into handling corrupted file
> systems as good as possible, although there are of course no guaranteeѕ.
> 
> The quote that you've taken out of context is for the legacy v4 format
> that has no checksums and other integrity features.

Ted's observation was about maliciously-crafted filesystems, though, so
integrity-only features such as metadata checksums are irrelevant.  Also the
filesystem version is irrelevant; anything accepted by the kernel code (even if
it's legacy/deprecated) is open attack surface.

I personally consider it *mandatory* that we deal with this stuff.  But I can
understand that we don't do a good job at it, so we shouldn't hold a new
filesystem to an unfairly high standard relative to other filesystems...

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reminder: 1 open syzbot bug in "android/ashmem" subsystem

[Eric Biggers]

[This email was generated by a script.  Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]

Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "android/ashmem" subsystem.

If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status

If you believe I misattributed this bug to the "android/ashmem" subsystem,
please let me know, and if possible forward the report to the correct people or
mailing list.

Here is the bug:


Title:  WARNING in __vm_enough_memory
Last occurred:  91 days ago
Reported:   554 days ago
Branches:   Mainline and others
Dashboard link: 
https://syzkaller.appspot.com/bug?id=52304f8f4b4e28508d52875f95df5e30417eff1b
Original thread:
https://lkml.kernel.org/lkml/001a1144593661efb50562d96...@google.com/T/#u

This bug has a C reproducer.

The original thread for this bug received 1 reply, 553 days ago.

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please consider replying to the
original thread.  For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/001a1144593661efb50562d96...@google.com

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reminder: 1 open syzbot bug in "android/ashmem" subsystem

[Eric Biggers]

[This email was generated by a script.  Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]

Of the currently open syzbot reports against the upstream kernel, I've manually
marked 1 of them as possibly being a bug in the "android/ashmem" subsystem.

If you believe this bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status

If you believe I misattributed this bug to the "android/ashmem" subsystem,
please let me know, and if possible forward the report to the correct people or
mailing list.

Here is the bug:


Title:  WARNING in __vm_enough_memory
Last occurred:  77 days ago
Reported:   539 days ago
Branches:   Mainline and others
Dashboard link: 
https://syzkaller.appspot.com/bug?id=52304f8f4b4e28508d52875f95df5e30417eff1b
Original thread:
https://lkml.kernel.org/lkml/001a1144593661efb50562d96...@google.com/T/#u

This bug has a C reproducer.

The original thread for this bug received 1 reply, 539 days ago.

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please consider replying to the
original thread.  For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/001a1144593661efb50562d96...@google.com

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reminder: 3 open syzbot bugs in "android/binder" subsystem

[Eric Biggers]

[This email was generated by a script.  Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]

Of the currently open syzbot reports against the upstream kernel, I've manually
marked 3 of them as possibly being bugs in the "android/binder" subsystem.  I've
listed these reports below, sorted by an algorithm that tries to list first the
reports most likely to be still valid, important, and actionable.

Of these 3 bugs, 1 was seen in mainline in the last week.

Of these 3 bugs, 1 was bisected to a commit from the following person:

Todd Kjos 

If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status

If you believe I misattributed a bug to the "android/binder" subsystem, please
let me know, and if possible forward the report to the correct people or mailing
list.

Here are the bugs:


Title:  kernel BUG at drivers/android/binder_alloc.c:LINE! (4)
Last occurred:  6 days ago
Reported:   14 days ago
Branches:   Mainline and others
Dashboard link: 
https://syzkaller.appspot.com/bug?id=bbf40136a49ffaa8ac60906edcbe77f825b2c406
Original thread:
https://lkml.kernel.org/lkml/b6b25b058b96d...@google.com/T/#u

This bug has a C reproducer.

This bug was bisected to:

commit bde4a19fc04f5f46298c86b1acb7a4af1d5f138d
Author: Todd Kjos 
Date:   Fri Feb 8 18:35:20 2019 +

  binder: use userspace pointer as base of buffer space

The original thread for this bug has received 3 replies; the last was 4 days
ago.

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3ae18325f96190606...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please reply to the original
thread, which had activity only 4 days ago.  For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at 
https://lkml.kernel.org/r/b6b25b058b96d...@google.com


Title:  WARNING in binder_transaction_buffer_release
Last occurred:  0 days ago
Reported:   43 days ago
Branches:   Mainline and others
Dashboard link: 
https://syzkaller.appspot.com/bug?id=4e0a6a529aef923a8d61c5d20b8fc0605c730138
Original thread:
https://lkml.kernel.org/lkml/afe2c70589526...@google.com/T/#u

This bug has a syzkaller reproducer only.

The original thread for this bug has received 2 replies; the last was 20 days
ago.

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8b3c354d33c4ac78b...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please consider replying to the
original thread.  For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/afe2c70589526...@google.com


Title:  possible deadlock in uprobe_clear_state
Last occurred:  165 days ago
Reported:   202 days ago
Branches:   Mainline
Dashboard link: 
https://syzkaller.appspot.com/bug?id=a1ce9b3da349209c5085bb8c4fee753d68c3697f
Original thread:
https://lkml.kernel.org/lkml/10a9fb057cd14...@google.com/T/#u

Unfortunately, this bug does not have a reproducer.

[Note: the uprobe developers think this is a bug in binder, not uprobes.
 See https://marc.info/?l=linux-kernel&m=155119805728815&w=2
 for a suggested fix for this bug.]

If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1068f09c44d151250...@syzkaller.appspotmail.com

If you send any email or patch for this bug, please consider replying to the
original thread.  For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/10a9fb057cd14...@google.com

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[ashmem] Re: WARNING in __vm_enough_memory

[Eric Biggers]

On Tue, Jan 16, 2018 at 06:20:37AM +0100, 'Dmitry Vyukov' via syzkaller-bugs 
wrote:
> 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.
> >

Can the ashmem maintainers please look into this?  syzbot has continue

Re: WARNING in binder_transaction_buffer_release

[Eric Biggers]

On Mon, May 20, 2019 at 07:18:06AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:72cf0b07 Merge tag 'sound-fix-5.2-rc1' of git://git.kernel..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17c7d4bca0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d103f114f9010324
> dashboard link: https://syzkaller.appspot.com/bug?extid=8b3c354d33c4ac78bfad
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> userspace arch: i386
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15b99b44a0
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+8b3c354d33c4ac78b...@syzkaller.appspotmail.com
> 
> WARNING: CPU: 1 PID: 8535 at drivers/android/binder.c:2368
> binder_transaction_buffer_release+0x673/0x8f0 drivers/android/binder.c:2368
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 8535 Comm: syz-executor.2 Not tainted 5.1.0+ #19
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x172/0x1f0 lib/dump_stack.c:113
>  panic+0x2cb/0x715 kernel/panic.c:214
>  __warn.cold+0x20/0x4c kernel/panic.c:571
>  report_bug+0x263/0x2b0 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:179 [inline]
>  fixup_bug arch/x86/kernel/traps.c:174 [inline]
>  do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
>  do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
> RIP: 0010:binder_transaction_buffer_release+0x673/0x8f0
> drivers/android/binder.c:2368
> Code: 31 ff 41 89 c5 89 c6 e8 7b 04 1f fc 45 85 ed 0f 85 1f 41 01 00 49 8d
> 47 40 48 89 85 50 fe ff ff e9 9d fa ff ff e8 dd 02 1f fc <0f> 0b e9 7f fc ff
> ff e8 d1 02 1f fc 48 89 d8 45 31 c9 4c 89 fe 4c
> RSP: 0018:88807b2775f0 EFLAGS: 00010293
> RAX: 888092b1e040 RBX: 0060 RCX: 111012563caa
> RDX:  RSI: 85519e13 RDI: 888097a2d248
> RBP: 88807b2777d8 R08: 888092b1e040 R09: ed100f64eee3
> R10: ed100f64eee2 R11: 88807b277717 R12: 88808fd2c340
> R13: 0068 R14: 88807b2777b0 R15: 88809f7ea580
>  binder_transaction+0x153d/0x6620 drivers/android/binder.c:3484
>  binder_thread_write+0x87e/0x2820 drivers/android/binder.c:3792
>  binder_ioctl_write_read drivers/android/binder.c:4836 [inline]
>  binder_ioctl+0x102f/0x1833 drivers/android/binder.c:5013
>  __do_compat_sys_ioctl fs/compat_ioctl.c:1052 [inline]
>  __se_compat_sys_ioctl fs/compat_ioctl.c:998 [inline]
>  __ia32_compat_sys_ioctl+0x195/0x620 fs/compat_ioctl.c:998
>  do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline]
>  do_fast_syscall_32+0x27b/0xd7d arch/x86/entry/common.c:408
>  entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> RIP: 0023:0xf7f9e849
> Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
> 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90
> 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
> RSP: 002b:f7f9a0cc EFLAGS: 0296 ORIG_RAX: 0036
> RAX: ffda RBX: 0004 RCX: c0306201
> RDX: 2140 RSI:  RDI: 
> RBP:  R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> 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.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
> 

Are any of the binder maintainers planning to fix this?  This seems to be the
only open syzbot report for binder on the upstream kernel.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/6] lib/crc32: treewide: Use existing define with polynomial

[Eric Biggers]

Hi Krzysztof,

On Tue, Jul 17, 2018 at 06:05:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Kernel defines same polynomial for CRC-32 in few places.
> This is unnecessary duplication of the same value. Also this might
> be error-prone for future code - every driver will define the
> polynomial again.
> 
> This is an attempt to unify definition of polynomial.  Few obvious
> hard-coded locations are fixed with define.
> 
> All series depend on each 1/6 and 2/6.
> 
> This could be merged in two different merge windows (1st lib/crc and then
> the rest) or taken through one tree.
> 
> It would be nice to get some testing. Only generic lib/crc, bunzip, xz_crc32
> and Freescale's Ethernet driver were tested on HW.  Rest got just different
> builds.
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (6):
>   lib/crc: Move polynomial definition to separate header
>   lib/crc: Use consistent naming for CRC-32 polynomials
>   crypto: stm32_crc32 - Use existing define with polynomial
>   net: ethernet: Use existing define with polynomial
>   staging: rtl: Use existing define with polynomial
>   lib: Use existing define with polynomial
> 
>  drivers/crypto/stm32/stm32_crc32.c   | 11 ---
>  drivers/net/ethernet/amd/xgbe/xgbe-dev.c |  4 ++--
>  drivers/net/ethernet/apple/bmac.c|  8 ++--
>  drivers/net/ethernet/broadcom/tg3.c  |  3 ++-
>  drivers/net/ethernet/freescale/fec_main.c|  4 ++--
>  drivers/net/ethernet/freescale/fs_enet/fec.h |  3 ---
>  drivers/net/ethernet/freescale/fs_enet/mac-fec.c |  3 ++-
>  drivers/net/ethernet/micrel/ks8851_mll.c |  3 ++-
>  drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c|  4 ++--
>  drivers/staging/rtl8712/rtl871x_security.c   |  5 ++---
>  drivers/staging/rtl8723bs/core/rtw_security.c|  5 ++---
>  include/linux/crc32poly.h| 20 
>  lib/crc32.c  | 11 ++-
>  lib/crc32defs.h  | 14 --
>  lib/decompress_bunzip2.c |  3 ++-
>  lib/gen_crc32table.c |  5 +++--
>  lib/xz/xz_crc32.c|  3 ++-
>  17 files changed, 55 insertions(+), 54 deletions(-)
>  create mode 100644 include/linux/crc32poly.h
> 

Did you check whether any of these users can be converted to use the CRC
implementations in lib/, so they wouldn't need the polynomial definition
themselves?

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: possible deadlock in vfs_fallocate

[Eric Biggers]

[+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)
> 
> 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]
>__sb_start_write+0x1e9/0x300 fs/super.c:1385
>file_start_write include/linux/fs.h:2718 [inline]
>vfs_fallocate+0x5be/0x8d0 fs/open.c:318
>ashmem_shrink_scan+0x1f1/0x560 drivers/staging/android/ashmem.c:447
>ashmem_ioctl+0x3bf/0x13a0 drivers/staging/android/ashmem.c:789
>vfs_ioctl fs/ioctl.c:46 [inline]
>file_ioctl fs/ioctl.c:500 [inline]
>do_vfs_ioctl+0x1cf/0x16a0 fs/ioctl.c:684
>ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
>__do_sys_ioctl fs/ioctl.c:708 [inline]
>  

Re: KASAN: use-after-free Read in binder_release_work

[Eric Biggers]

On Tue, Apr 03, 2018 at 08:02:02PM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> f2d285669aae656dfeafa0bf25e86bbbc5d22329 (Tue Apr 3 17:45:39 2018 +)
> Merge tag 'pm-4.17-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=0cf1f1aa154f56ff2e8d
> 
> So far this crash happened 4 times on upstream.
> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4827186146050048
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=6025869373997056
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=4772918563176448
> Kernel config: https://syzkaller.appspot.com/x/.config?id=686016073509112605
> compiler: gcc (GCC) 7.1.1 20170620
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+0cf1f1aa154f56ff2...@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.
> 
> binder: 4616:4618 transaction failed 29189/-3, size 0-0 line 2963
> binder: release 4616:4618 transaction 114 in, still active
> binder: send failed reply for transaction 114 to 4616:4618
> binder: 4620:4621 ioctl 400448c8 2200 returned -22
> ==
> BUG: KASAN: use-after-free in __list_del_entry_valid+0x144/0x150
> lib/list_debug.c:54
> Read of size 8 at addr 8801d39a4210 by task kworker/1:2/1891
> 
> CPU: 1 PID: 1891 Comm: kworker/1:2 Not tainted 4.16.0+ #378
> binder: release 4620:4621 transaction 118 out, still active
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events binder_deferred_func
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x1a7/0x27d lib/dump_stack.c:53
> binder: release 4620:4621 transaction 117 in, still active
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
> binder: undelivered TRANSACTION_COMPLETE
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23c/0x360 mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> binder: BINDER_SET_CONTEXT_MGR already set
>  __list_del_entry_valid+0x144/0x150 lib/list_debug.c:54
> binder: 4620:4622 ioctl 40046207 0 returned -16
>  __list_del_entry include/linux/list.h:117 [inline]
>  list_del_init include/linux/list.h:159 [inline]
>  binder_dequeue_work_head_ilocked drivers/android/binder.c:893 [inline]
>  binder_dequeue_work_head drivers/android/binder.c:913 [inline]
>  binder_release_work+0x163/0x4b0 drivers/android/binder.c:4191
> binder: 4620:4621 ioctl c0306201 20004000 returned -14
> binder: 4620:4621 ioctl 400448c8 2200 returned -22
>  binder_thread_release+0x4e1/0x730 drivers/android/binder.c:4396
> binder_alloc: binder_alloc_mmap_handler: 4620 2000c000-2000e000 already
> mapped failed -16
>  binder_deferred_release drivers/android/binder.c:4939 [inline]
>  binder_deferred_func+0x4f4/0x1350 drivers/android/binder.c:5022
> binder_alloc: 4620: binder_alloc_buf, no vma
> binder: 4620:4623 transaction failed 29189/-3, size 0-0 line 2963
>  process_one_work+0xc97/0x1c40 kernel/workqueue.c:2113
> binder_alloc: 4620: binder_alloc_buf, no vma
> binder: 4620:4621 transaction failed 29189/-3, size 0-0 line 2963
> binder: release 4620:4622 transaction 118 in, still active
> binder: release 4620:4622 transaction 117 out, still active
>  worker_thread+0x1c3/0x1380 kernel/workqueue.c:2247
> binder: send failed reply for transaction 118, target dead
> binder: send failed reply for transaction 117, target dead
> binder: BINDER_SET_CONTEXT_MGR already set
> binder: 4624:4625 ioctl 40046207 0 returned -16
>  kthread+0x33c/0x400 kernel/kthread.c:238
> binder: 4624:4625 ioctl 400448c8 2200 returned -22
>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:411
> 
> binder_alloc: 4620: binder_alloc_buf, no vma
> Allocated by task 4618:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
> binder: 4624:4626 transaction failed 29189/-3, size 0-0 line 2963
>  kmem_cache_alloc_trace+0x136/0x740 mm/slab.c:3608
>  kmalloc include/linux/slab.h:512 [inline]
>  kzalloc include/linux/slab.h:701 [inline]
>  binder_transaction+0x13d2/0x8200 drivers/android/binder.c:2900
>  binder_thread_write+0xcf1/0x38b0 drivers/android/binder.c:3513
>  binder_ioctl_write_read.isra.39+0x261/0xcb0 drivers/android/binder.c:4451
>  binder_ioctl+0xb72/0x1417 drivers/android/binder.c:4591
> binder: undelivered TRANSACTION_ERROR: 29189
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>  ksys_ioctl+0x94/0xb0 fs/ioctl.c:701
>  SYSC_ioctl fs/ioctl.c:708 [inline]
>  SyS_ioctl+0x24/0x30 fs/ioctl.c:706
>  do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+

Re: WARNING in binder_send_failed_reply

[Eric Biggers]

On Tue, Dec 26, 2017 at 02:20:01PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 0e08c463db387a2adcb0243b15ab868a73f87807
> 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
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by:
> 
> It will help syzbot understand when the bug is fixed.
> 
> binder: undelivered TRANSACTION_COMPLETE
> binder: undelivered TRANSACTION_ERROR: 29189
> binder: send failed reply for transaction 844 to 4059:4061
> [ cut here ]
> Unexpected reply error: 29189
> WARNING: CPU: 0 PID: 1409 at drivers/android/binder.c:1998
> binder_send_failed_reply+0x13b/0x390 drivers/android/binder.c:1997
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 0 PID: 1409 Comm: kworker/0:2 Not tainted 4.15.0-rc4-next-20171221+ #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events binder_deferred_func
> 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:177
>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:binder_send_failed_reply+0x13b/0x390 drivers/android/binder.c:1997
> RSP: 0018:8801d3887128 EFLAGS: 00010286
> RAX: dc08 RBX: 8801c2fbce00 RCX: 8159f9ce
> RDX:  RSI: 11003a70c91d RDI: 0293
> RBP: 8801d3887150 R08: 11003a710db8 R09: 
> R10: 8801d3886fa0 R11:  R12: 8801bf73a840
> R13: 7205 R14: 7205 R15: 0fdb
>  binder_cleanup_transaction+0xd2/0x140 drivers/android/binder.c:2035
>  binder_release_work+0x340/0x490 drivers/android/binder.c:4198
>  binder_deferred_release drivers/android/binder.c:4951 [inline]
>  binder_deferred_func+0xe42/0x1340 drivers/android/binder.c:4996
>  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2112
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 

syzbot is no longer hitting this because the WARN() was removed by commit
e46a3b3ba7509c:

#syz fix: ANDROID: binder: remove WARN() for redundant txn error

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: kernel BUG at drivers/android/binder_alloc.c:LINE!

[Eric Biggers]

On Fri, Dec 01, 2017 at 04:22:00PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 3c1c4ddffb58b9e10b3365764fe59546130b3f32
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> binder: 3087:3087 ERROR: BC_REGISTER_LOOPER called without request
> binder: 3087:3087 ioctl c0306201 2000dfd0 returned -14
> [ cut here ]
> kernel BUG at drivers/android/binder_alloc.c:750!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 1404 Comm: kworker/0:2 Not tainted 4.15.0-rc1+ #203
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events binder_deferred_func
> task: 09b739b6 task.stack: c1d4442c
> RIP: 0010:binder_alloc_deferred_release+0x146/0xa40
> drivers/android/binder_alloc.c:750
> RSP: 0018:8801d2b16fd8 EFLAGS: 00010293
> RAX: 8801d2b08080 RBX: 8801d7829300 RCX: 8403b856
> RDX:  RSI: 0004 RDI: 8801d7829330
> RBP: 8801d2b17138 R08: 8403b7d9 R09: 10e53001
> R10: 8801d2b16fc8 R11: 87489d60 R12: 
> R13: dc00 R14: 8801d2b17110 R15: 8801d7829310
> FS:  () GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 006d00a8 CR3: 05e25000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  binder_free_proc drivers/android/binder.c:4200 [inline]
>  binder_proc_dec_tmpref+0x2f3/0x420 drivers/android/binder.c:1833
>  binder_deferred_release drivers/android/binder.c:4858 [inline]
>  binder_deferred_func+0xe22/0x12f0 drivers/android/binder.c:4893
>  process_one_work+0xbfd/0x1be0 kernel/workqueue.c:2112
>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>  kthread+0x37a/0x440 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:441
> Code: e8 00 40 6c fd 49 8d 7f 20 49 8d 5f f0 48 89 fa 48 c1 ea 03 42 80 3c
> 2a 00 0f 85 84 07 00 00 49 83 7f 20 00 74 a9 e8 da 3f 6c fd <0f> 0b 48 8b 9d
> e8 fe ff ff 44 89 a5 bc fe ff ff e8 c5 3f 6c fd
> RIP: binder_alloc_deferred_release+0x146/0xa40
> drivers/android/binder_alloc.c:750 RSP: 8801d2b16fd8
> ---[ end trace 616e085d0dbf3c21 ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

This crash stopped occurring in v4.15-rc3, and I verified that it was commit
fb2c445277e which fixed it (thanks Martijn!).  So, telling syzbot so that it can
start reporting similar crashes again:

#syz fix: ANDROID: binder: fix transaction leak.

- Eric
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] binder: check for binder_thread allocation failure in binder_poll()

[Eric Biggers]

From: Eric Biggers 

If the kzalloc() in binder_get_thread() fails, binder_poll()
dereferences the resulting NULL pointer.

Fix it by returning POLLERR if the memory allocation failed.

This bug was found by syzkaller using fault injection.

Reported-by: syzbot 
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers 
---
 drivers/android/binder.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index d21040c5d343f..326ca8ea9ebcf 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4391,6 +4391,8 @@ static __poll_t binder_poll(struct file *filp,
bool wait_for_proc_work;
 
thread = binder_get_thread(proc);
+   if (!thread)
+   return POLLERR;
 
binder_inner_proc_lock(thread->proc);
thread->looper |= BINDER_LOOPER_STATE_POLL;
-- 
2.16.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: BUG: unable to handle kernel NULL pointer dereference in binder_poll

[Eric Biggers]

On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> 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
> 
> 
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> PGD 2134c1067 P4D 2134c1067 PUD 214180067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3117 Comm: syzkaller406906 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> RSP: 0018:c900017d3df0 EFLAGS: 00010286
> RAX:  RBX: c900017d3ef0 RCX: 820258f3
> RDX:  RSI: 83080700 RDI: 0286
> RBP: c900017d3e20 R08:  R09: 
> R10:  R11:  R12: c900017d3ef0
> R13: 8802118fb000 R14: 82bb9f20 R15: 8802140d1c30
> FS:  00deb880() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000216bbc002 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  ep_item_poll.isra.10+0x49/0xf0 fs/eventpoll.c:885
>  ep_insert fs/eventpoll.c:1457 [inline]
>  SYSC_epoll_ctl fs/eventpoll.c:2104 [inline]
>  SyS_epoll_ctl+0x884/0x1010 fs/eventpoll.c:1990
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x444119
> RSP: 002b:7fffbc6b55b8 EFLAGS: 0246 ORIG_RAX: 00e9
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> Code: ff 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fd 53 49 89 f4 48
> 83 ec 08 e8 24 49 29 ff 49 8b bd 90 01 00 00 e8 78 fd ff ff <48> 8b 38 48 89
> c3 be 15 11 00 00 e8 e8 7e ff ff 44 8b 73 34 44
> RIP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371 RSP:
> c900017d3df0
> CR2: 

Duplicate of:

#syz dup: general protection fault in binder_poll
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: BUG: unable to handle kernel NULL pointer dereference in binder_deferred_func

[Eric Biggers]

On Tue, Dec 19, 2017 at 08:25:00AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> 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.
> 
> Unfortunately, I don't have any reproducer for this bug yet.
> 
> 
> binder: 5029:5034 got transaction to invalid handle
> binder: 5029:5034 transaction failed 29201/-22, size 0-56 line 2832
> binder: undelivered TRANSACTION_ERROR: 29201
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: __hlist_del include/linux/list.h:650 [inline]
> IP: hlist_del include/linux/list.h:656 [inline]
> IP: binder_deferred_release drivers/android/binder.c:4869 [inline]
> IP: binder_deferred_func+0x172/0x760 drivers/android/binder.c:4978
> PGD 1d6fa0067 P4D 1d6fa0067 PUD 1dd31d067 PMD 0
> Oops: 0002 [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3384 Comm: kworker/0:3 Not tainted 4.15.0-rc3-next-20171214+ #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events binder_deferred_func
> RIP: 0010:__hlist_del include/linux/list.h:650 [inline]
> RIP: 0010:hlist_del include/linux/list.h:656 [inline]
> RIP: 0010:binder_deferred_release drivers/android/binder.c:4869 [inline]
> RIP: 0010:binder_deferred_func+0x172/0x760 drivers/android/binder.c:4978
> RSP: 0018:c90002c83de8 EFLAGS: 00010246
> RAX:  RBX:  RCX: 82e4c35e
> RDX: 8802156dc5c0 RSI: 3f65f67c RDI: 
> RBP: c90002c83e48 R08: 82021bf5 R09: 0004
> R10: c90002c83dd8 R11: 0004 R12: 8801de9ce458
> R13: 880215760160 R14:  R15: 8801de9ce400
> FS:  () GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 0001d6fa1000 CR4: 001406f0
> Call Trace:
>  process_one_work+0x288/0x7a0 kernel/workqueue.c:2112
>  worker_thread+0x43/0x4d0 kernel/workqueue.c:2246
>  kthread+0x149/0x170 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
> Code: 24 58 02 00 00 0f 85 8b 05 00 00 e8 59 87 29 ff 31 f6 48 c7 c7 80 bd
> 15 83 e8 4b a1 5a 00 49 8b 5c 24 a8 4d 8b 74 24 b0 48 85 db <49> 89 1e 74 09
> e8 34 87 29 ff 4c 89 73 08 e8 2b 87 29 ff 48 b8
> RIP: __hlist_del include/linux/list.h:650 [inline] RSP: c90002c83de8
> RIP: hlist_del include/linux/list.h:656 [inline] RSP: c90002c83de8
> RIP: binder_deferred_release drivers/android/binder.c:4869 [inline] RSP:
> c90002c83de8
> RIP: binder_deferred_func+0x172/0x760 drivers/android/binder.c:4978 RSP:
> c90002c83de8
> CR2: 
> ---[ end trace 043d80c4b2730aca ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

Invalidating this bug since it hasn't been seen again, and it was reported while
KASAN was accidentally disabled in the syzbot kconfig due to a change to the
kconfig menus in linux-next (so this crash was possibly caused by slab
corruption elsewhere).

#syz invalid
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: binder epoll bug (was KASAN: use-after-free Read in __lock_acquire (2))

[Eric Biggers]

On Tue, Dec 12, 2017 at 04:05:17PM -0800, Eric Biggers wrote:
> [+Cc binder maintainers and list]
> [-Cc lockdep maintainers, USB maintainers, and other random people]
> 
> On Sat, Dec 02, 2017 at 08:08:01AM -0800, syzbot wrote:
> > BUG: KASAN: use-after-free in __lock_acquire+0x465e/0x47f0
> > kernel/locking/lockdep.c:3378
> > Read of size 8 at addr 8801cd8e13f0 by task syzkaller236979/3086
> > 
> > CPU: 1 PID: 3086 Comm: syzkaller236979 Not tainted 4.15.0-rc1+ #115
> > 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
> >  print_address_description+0x73/0x250 mm/kasan/report.c:252
> >  kasan_report_error mm/kasan/report.c:351 [inline]
> >  kasan_report+0x25b/0x340 mm/kasan/report.c:409
> >  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
> >  __lock_acquire+0x465e/0x47f0 kernel/locking/lockdep.c:3378
> >  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:4004
> >  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> >  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:159
> >  remove_wait_queue+0x81/0x350 kernel/sched/wait.c:50
> >  ep_remove_wait_queue fs/eventpoll.c:595 [inline]
> >  ep_unregister_pollwait.isra.7+0x18c/0x590 fs/eventpoll.c:613
> >  ep_free+0x13f/0x320 fs/eventpoll.c:830
> >  ep_eventpoll_release+0x44/0x60 fs/eventpoll.c:862
> >  __fput+0x333/0x7f0 fs/file_table.c:210
> >  fput+0x15/0x20 fs/file_table.c:244
> >  task_work_run+0x199/0x270 kernel/task_work.c:113
> >  exit_task_work include/linux/task_work.h:22 [inline]
> >  do_exit+0x9bb/0x1ae0 kernel/exit.c:865
> >  do_group_exit+0x149/0x400 kernel/exit.c:968
> >  SYSC_exit_group kernel/exit.c:979 [inline]
> >  SyS_exit_group+0x1d/0x20 kernel/exit.c:977
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
> >  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
> >  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> > RIP: 0023:0xf7f97c79
> > RSP: 002b:ffcb51bc EFLAGS: 0296 ORIG_RAX: 00fc
> > RAX: ffda RBX:  RCX: 080f0298
> > RDX:  RSI: 080d9b18 RDI: 080f02a0
> > RBP: 0001 R08:  R09: 
> > R10:  R11:  R12: 
> > R13:  R14:  R15: 
> > 
> > Allocated by task 3086:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >  set_track mm/kasan/kasan.c:459 [inline]
> >  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
> >  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3613
> >  kmalloc include/linux/slab.h:499 [inline]
> >  kzalloc include/linux/slab.h:688 [inline]
> >  binder_get_thread+0x1cf/0x870 drivers/android/binder.c:4184
> >  binder_poll+0x8c/0x390 drivers/android/binder.c:4286
> >  ep_item_poll.isra.10+0xec/0x320 fs/eventpoll.c:884
> >  ep_insert+0x6a3/0x1b10 fs/eventpoll.c:1455
> >  SYSC_epoll_ctl fs/eventpoll.c:2106 [inline]
> >  SyS_epoll_ctl+0x12e4/0x1ab0 fs/eventpoll.c:1992
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
> >  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
> >  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> > 
> > Freed by task 3086:
> >  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >  set_track mm/kasan/kasan.c:459 [inline]
> >  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
> >  __cache_free mm/slab.c:3491 [inline]
> >  kfree+0xca/0x250 mm/slab.c:3806
> >  binder_free_thread drivers/android/binder.c:4211 [inline]
> >  binder_thread_dec_tmpref+0x27f/0x310 drivers/android/binder.c:1808
> >  binder_thread_release+0x27d/0x540 drivers/android/binder.c:4275
> >  binder_ioctl+0xc05/0x141a drivers/android/binder.c:4492
> >  C_SYSC_ioctl fs/compat_ioctl.c:1473 [inline]
> >  compat_SyS_ioctl+0x151/0x2a30 fs/compat_ioctl.c:1419
> >  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
> >  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
> >  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> 
> This is a bug in the binder driver.  binder_poll() tells the poll system to 
> use
> the wait queue embedded in the 'struct binder_thread', but then the
> BINDER_THREAD_EXIT ioctl will free the 'struct binder_thread' out from under 
> it.
> 
> Perhaps either the waitqueue should be associated with th

binder epoll bug (was KASAN: use-after-free Read in __lock_acquire (2))

[Eric Biggers]

[+Cc binder maintainers and list]
[-Cc lockdep maintainers, USB maintainers, and other random people]

On Sat, Dec 02, 2017 at 08:08:01AM -0800, syzbot wrote:
> BUG: KASAN: use-after-free in __lock_acquire+0x465e/0x47f0
> kernel/locking/lockdep.c:3378
> Read of size 8 at addr 8801cd8e13f0 by task syzkaller236979/3086
> 
> CPU: 1 PID: 3086 Comm: syzkaller236979 Not tainted 4.15.0-rc1+ #115
> 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
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>  __lock_acquire+0x465e/0x47f0 kernel/locking/lockdep.c:3378
>  lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:4004
>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>  _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:159
>  remove_wait_queue+0x81/0x350 kernel/sched/wait.c:50
>  ep_remove_wait_queue fs/eventpoll.c:595 [inline]
>  ep_unregister_pollwait.isra.7+0x18c/0x590 fs/eventpoll.c:613
>  ep_free+0x13f/0x320 fs/eventpoll.c:830
>  ep_eventpoll_release+0x44/0x60 fs/eventpoll.c:862
>  __fput+0x333/0x7f0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ae0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  SYSC_exit_group kernel/exit.c:979 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:977
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> RIP: 0023:0xf7f97c79
> RSP: 002b:ffcb51bc EFLAGS: 0296 ORIG_RAX: 00fc
> RAX: ffda RBX:  RCX: 080f0298
> RDX:  RSI: 080d9b18 RDI: 080f02a0
> RBP: 0001 R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> 
> Allocated by task 3086:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3613
>  kmalloc include/linux/slab.h:499 [inline]
>  kzalloc include/linux/slab.h:688 [inline]
>  binder_get_thread+0x1cf/0x870 drivers/android/binder.c:4184
>  binder_poll+0x8c/0x390 drivers/android/binder.c:4286
>  ep_item_poll.isra.10+0xec/0x320 fs/eventpoll.c:884
>  ep_insert+0x6a3/0x1b10 fs/eventpoll.c:1455
>  SYSC_epoll_ctl fs/eventpoll.c:2106 [inline]
>  SyS_epoll_ctl+0x12e4/0x1ab0 fs/eventpoll.c:1992
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
> 
> Freed by task 3086:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3491 [inline]
>  kfree+0xca/0x250 mm/slab.c:3806
>  binder_free_thread drivers/android/binder.c:4211 [inline]
>  binder_thread_dec_tmpref+0x27f/0x310 drivers/android/binder.c:1808
>  binder_thread_release+0x27d/0x540 drivers/android/binder.c:4275
>  binder_ioctl+0xc05/0x141a drivers/android/binder.c:4492
>  C_SYSC_ioctl fs/compat_ioctl.c:1473 [inline]
>  compat_SyS_ioctl+0x151/0x2a30 fs/compat_ioctl.c:1419
>  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
>  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
>  entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125

This is a bug in the binder driver.  binder_poll() tells the poll system to use
the wait queue embedded in the 'struct binder_thread', but then the
BINDER_THREAD_EXIT ioctl will free the 'struct binder_thread' out from under it.

Perhaps either the waitqueue should be associated with the 'struct binder_proc'
rather than the 'struct binder_thread', or binder_poll() should take a reference
to the 'struct binder_thread'.  But I'm not too familiar with binder or epoll,
so I don't know which solution is best.

Here is a program which reproduces the bug, assuming /dev/binder0 exists:

#include 
#include 
#include 
#include 

#define BINDER_THREAD_EXIT 0x40046208ul

int main()
{
int fd, epfd;
struct epoll_event event = { .events = EPOLLIN };

fd = open("/dev/binder0", O_RDONLY);
epfd = epoll_create(1000);
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
ioctl(f