Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Mike Kravetz
On 03/23/2017 06:49 AM, Tetsuo Handa wrote:
> Dmitry Vyukov wrote:
>> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
>>> Hello,
>>>
>>> I've got the following report while running syzkaller fuzzer on
>>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
>>> kmalloc failure in inode_alloc_security, most likely it's the root
>>> cause.
> 
> I don't think inode_alloc_security() failure is the root cause.
> I think this is a bug in hugetlbfs or mm part.
> 
> If inode_alloc_security() fails, inode->i_security remains NULL
> which was initialized to NULL at security_inode_alloc(). Thus,
> security_inode_alloc() is irrelevant to this problem.
> 
> inode_init_always() returned -ENOMEM due to fault injection and
> 
>   if (unlikely(inode_init_always(sb, inode))) {
>   if (inode->i_sb->s_op->destroy_inode)
>   inode->i_sb->s_op->destroy_inode(inode);
>   else
>   kmem_cache_free(inode_cachep, inode);
>   return NULL;
>   }
> 
> hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
> when inode initialization failed
> 
> static void hugetlbfs_destroy_inode(struct inode *inode)
> {
>   hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
>   mpol_free_shared_policy(_I(inode)->policy);
>   call_rcu(>i_rcu, hugetlbfs_i_callback);
> }
> 
> but mpol_shared_policy_init() is called only when new_inode() succeeds.
> 
>   inode = new_inode(sb);
>   if (inode) {
> (...snipped...)
>   info = HUGETLBFS_I(inode);
>   /*
>* The policy is initialized here even if we are creating a
>* private inode because initialization simply creates an
>* an empty rb tree and calls rwlock_init(), later when we
>* call mpol_free_shared_policy() it will just return because
>* the rb tree will still be empty.
>*/
>   mpol_shared_policy_init(>policy, NULL);
> 

Thank you for analysis (and Dmitry for reporting).

This certainly does look like a hugetlbfs bug.  I will put together a
patch to fix.

-- 
Mike Kravetz


Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Mike Kravetz
On 03/23/2017 06:49 AM, Tetsuo Handa wrote:
> Dmitry Vyukov wrote:
>> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
>>> Hello,
>>>
>>> I've got the following report while running syzkaller fuzzer on
>>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
>>> kmalloc failure in inode_alloc_security, most likely it's the root
>>> cause.
> 
> I don't think inode_alloc_security() failure is the root cause.
> I think this is a bug in hugetlbfs or mm part.
> 
> If inode_alloc_security() fails, inode->i_security remains NULL
> which was initialized to NULL at security_inode_alloc(). Thus,
> security_inode_alloc() is irrelevant to this problem.
> 
> inode_init_always() returned -ENOMEM due to fault injection and
> 
>   if (unlikely(inode_init_always(sb, inode))) {
>   if (inode->i_sb->s_op->destroy_inode)
>   inode->i_sb->s_op->destroy_inode(inode);
>   else
>   kmem_cache_free(inode_cachep, inode);
>   return NULL;
>   }
> 
> hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
> when inode initialization failed
> 
> static void hugetlbfs_destroy_inode(struct inode *inode)
> {
>   hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
>   mpol_free_shared_policy(_I(inode)->policy);
>   call_rcu(>i_rcu, hugetlbfs_i_callback);
> }
> 
> but mpol_shared_policy_init() is called only when new_inode() succeeds.
> 
>   inode = new_inode(sb);
>   if (inode) {
> (...snipped...)
>   info = HUGETLBFS_I(inode);
>   /*
>* The policy is initialized here even if we are creating a
>* private inode because initialization simply creates an
>* an empty rb tree and calls rwlock_init(), later when we
>* call mpol_free_shared_policy() it will just return because
>* the rb tree will still be empty.
>*/
>   mpol_shared_policy_init(>policy, NULL);
> 

Thank you for analysis (and Dmitry for reporting).

This certainly does look like a hugetlbfs bug.  I will put together a
patch to fix.

-- 
Mike Kravetz


Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Tetsuo Handa
Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> > Hello,
> >
> > I've got the following report while running syzkaller fuzzer on
> > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> > kmalloc failure in inode_alloc_security, most likely it's the root
> > cause.

I don't think inode_alloc_security() failure is the root cause.
I think this is a bug in hugetlbfs or mm part.

If inode_alloc_security() fails, inode->i_security remains NULL
which was initialized to NULL at security_inode_alloc(). Thus,
security_inode_alloc() is irrelevant to this problem.

inode_init_always() returned -ENOMEM due to fault injection and

if (unlikely(inode_init_always(sb, inode))) {
if (inode->i_sb->s_op->destroy_inode)
inode->i_sb->s_op->destroy_inode(inode);
else
kmem_cache_free(inode_cachep, inode);
return NULL;
}

hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
when inode initialization failed

static void hugetlbfs_destroy_inode(struct inode *inode)
{
hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
mpol_free_shared_policy(_I(inode)->policy);
call_rcu(>i_rcu, hugetlbfs_i_callback);
}

but mpol_shared_policy_init() is called only when new_inode() succeeds.

inode = new_inode(sb);
if (inode) {
(...snipped...)
info = HUGETLBFS_I(inode);
/*
 * The policy is initialized here even if we are creating a
 * private inode because initialization simply creates an
 * an empty rb tree and calls rwlock_init(), later when we
 * call mpol_free_shared_policy() it will just return because
 * the rb tree will still be empty.
 */
mpol_shared_policy_init(>policy, NULL);


Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Tetsuo Handa
Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> > Hello,
> >
> > I've got the following report while running syzkaller fuzzer on
> > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> > kmalloc failure in inode_alloc_security, most likely it's the root
> > cause.

I don't think inode_alloc_security() failure is the root cause.
I think this is a bug in hugetlbfs or mm part.

If inode_alloc_security() fails, inode->i_security remains NULL
which was initialized to NULL at security_inode_alloc(). Thus,
security_inode_alloc() is irrelevant to this problem.

inode_init_always() returned -ENOMEM due to fault injection and

if (unlikely(inode_init_always(sb, inode))) {
if (inode->i_sb->s_op->destroy_inode)
inode->i_sb->s_op->destroy_inode(inode);
else
kmem_cache_free(inode_cachep, inode);
return NULL;
}

hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
when inode initialization failed

static void hugetlbfs_destroy_inode(struct inode *inode)
{
hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
mpol_free_shared_policy(_I(inode)->policy);
call_rcu(>i_rcu, hugetlbfs_i_callback);
}

but mpol_shared_policy_init() is called only when new_inode() succeeds.

inode = new_inode(sb);
if (inode) {
(...snipped...)
info = HUGETLBFS_I(inode);
/*
 * The policy is initialized here even if we are creating a
 * private inode because initialization simply creates an
 * an empty rb tree and calls rwlock_init(), later when we
 * call mpol_free_shared_policy() it will just return because
 * the rb tree will still be empty.
 */
mpol_shared_policy_init(>policy, NULL);


Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure in inode_alloc_security, most likely it's the root
> cause.
>
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  inode_alloc_security security/selinux/hooks.c:221 [inline]
>  selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
>  security_inode_alloc+0x90/0xd0 security/security.c:387
>  inode_init_always+0x5af/0xc20 fs/inode.c:166
>  alloc_inode+0x82/0x180 fs/inode.c:214
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==
> BUG: KASAN: user-memory-access in atomic_inc
> include/asm-generic/atomic-instrumented.h:87 [inline] at addr
> 00131730bd7a
> BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
> kernel/locking/lockdep.c:3239 at addr 00131730bd7a
> Write of size 4 by task syz-executor6/14086
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
>  kasan_report+0x21/0x30 mm/kasan/report.c:303
>  check_memory_region_inline mm/kasan/kasan.c:326 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
>  kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
>  atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
>  __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
>  lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
>  __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
>  _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
>  mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
>  hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
>  alloc_inode+0x10d/0x180 fs/inode.c:216
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==


Similar on address 0x2d302e31312e35c7, looks like uninit.

==
BUG: KASAN: wild-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
2d302e31312e35c7
BUG: KASAN: wild-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 2d302e31312e35c7
Write of size 4 by task syz-executor1/9446
CPU: 1 PID: 9446 Comm: syz-executor1 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC 

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure in inode_alloc_security, most likely it's the root
> cause.
>
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  inode_alloc_security security/selinux/hooks.c:221 [inline]
>  selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
>  security_inode_alloc+0x90/0xd0 security/security.c:387
>  inode_init_always+0x5af/0xc20 fs/inode.c:166
>  alloc_inode+0x82/0x180 fs/inode.c:214
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==
> BUG: KASAN: user-memory-access in atomic_inc
> include/asm-generic/atomic-instrumented.h:87 [inline] at addr
> 00131730bd7a
> BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
> kernel/locking/lockdep.c:3239 at addr 00131730bd7a
> Write of size 4 by task syz-executor6/14086
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
>  kasan_report+0x21/0x30 mm/kasan/report.c:303
>  check_memory_region_inline mm/kasan/kasan.c:326 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
>  kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
>  atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
>  __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
>  lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
>  __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
>  _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
>  mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
>  hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
>  alloc_inode+0x10d/0x180 fs/inode.c:216
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==


Similar on address 0x2d302e31312e35c7, looks like uninit.

==
BUG: KASAN: wild-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
2d302e31312e35c7
BUG: KASAN: wild-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 2d302e31312e35c7
Write of size 4 by task syz-executor1/9446
CPU: 1 PID: 9446 Comm: syz-executor1 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure in inode_alloc_security, most likely it's the root
cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 inode_alloc_security security/selinux/hooks.c:221 [inline]
 selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
 security_inode_alloc+0x90/0xd0 security/security.c:387
 inode_init_always+0x5af/0xc20 fs/inode.c:166
 alloc_inode+0x82/0x180 fs/inode.c:214
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
00131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 00131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
 kasan_report+0x21/0x30 mm/kasan/report.c:303
 check_memory_region_inline mm/kasan/kasan.c:326 [inline]
 check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
 atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
 __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
 _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
 mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
 hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
 alloc_inode+0x10d/0x180 fs/inode.c:216
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==


security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

2017-03-23 Thread Dmitry Vyukov
Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure in inode_alloc_security, most likely it's the root
cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 inode_alloc_security security/selinux/hooks.c:221 [inline]
 selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
 security_inode_alloc+0x90/0xd0 security/security.c:387
 inode_init_always+0x5af/0xc20 fs/inode.c:166
 alloc_inode+0x82/0x180 fs/inode.c:214
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
00131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 00131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
 kasan_report+0x21/0x30 mm/kasan/report.c:303
 check_memory_region_inline mm/kasan/kasan.c:326 [inline]
 check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
 atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
 __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
 _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
 mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
 hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
 alloc_inode+0x10d/0x180 fs/inode.c:216
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==