lkml.org 
[lkml]   [2014]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] vfs: Fix possible NULL pointer dereference in inode_permission()
    On Thu, 9 Jan 2014 15:45:37 -0800
    "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

    > > static void inode_free_security(struct inode *inode)
    > > {
    > > struct inode_security_struct *isec = inode->i_security;
    > > @@ -244,8 +252,7 @@ static void inode_free_security(struct i
    > > list_del_init(&isec->list);
    > > spin_unlock(&sbsec->isec_lock);
    > >
    > > - inode->i_security = NULL;
    > > - kmem_cache_free(sel_inode_cache, isec);
    > > + call_rcu(&isec->rcu, inode_free_rcu);
    >
    > Does not clearing ->i_security mean that RCU readers can traverse
    > this pointer after the invocation of call_rcu()? If so, this is
    > problematic. (If something else already prevents readers from getting
    > here, no problem.)

    This is called when we are about to free the inode. Look at
    destroy_inode(). Basically, this is the same as doing:

    call_rcu(&isec->rcu, inode_free_rcu);
    call_rcu(&inode->i_rcu, i_callback);

    Where i_callback() does the free of the inode.

    If you can access inode->i_security, after a call_rcu, then you can
    also access the inode itself that has just been freed.

    Yes, technically, having two separate call_rcu(), the first grace
    period can end before the second, but everything to remove the inode
    from sight has already been set up before that first call_rcu() is
    made. That means when the first call_rcu() is executed, the inode
    should already be invisible to the readers.


    - Steve

    >
    > Thanx, Paul
    >
    > > }
    > >


    \
     
     \ /
      Last update: 2014-01-10 01:41    [W:2.961 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site