linux-kernel - Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <844751a3-f77b-4319-a908-6f7237536812@oracle.com>
Date:   Thu, 23 Mar 2017 13:34:35 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        dvyukov@...gle.com, nyc@...omorphy.com,
        linux-kernel@...r.kernel.org, paul@...l-moore.com,
        sds@...ho.nsa.gov, eparis@...isplace.org,
        james.l.morris@...cle.com, serge@...lyn.com, keescook@...omium.org,
        anton@...msg.org, ccross@...roid.com, tony.luck@...el.com,
        selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org,
        linux-mm@...ck.org
Cc:     syzkaller@...glegroups.com
Subject: Re: security, hugetlbfs: write to user memory in
 hugetlbfs_destroy_inode

On 03/23/2017 06:49 AM, Tetsuo Handa wrote:
> Dmitry Vyukov wrote:
>> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov <dvyukov@...gle.com> 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(&HUGETLBFS_I(inode)->policy);
> 	call_rcu(&inode->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(&info->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