Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1607887
| From | Mike Kravetz <mike.kravetz@oracle.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode |
| Date | 2017-03-23 21:40 +0100 |
| Message-ID | <tohGy-7w7-23@gated-at.bofh.it> (permalink) |
| References | <toaF4-2Eh-17@gated-at.bofh.it> <toaF4-2Eh-21@gated-at.bofh.it> <tobhM-2SB-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@google.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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode Dmitry Vyukov <dvyukov@google.com> - 2017-03-23 14:10 +0100
Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode Dmitry Vyukov <dvyukov@google.com> - 2017-03-23 14:10 +0100
Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-03-23 14:50 +0100
Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode Mike Kravetz <mike.kravetz@oracle.com> - 2017-03-23 21:40 +0100
csiph-web