lkml.org 
[lkml]   [2013]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 3.12 060/116] NFSv4: Fix a use-after-free situation in _nfs4_proc_getlk()
    Date
    3.12-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Trond Myklebust <Trond.Myklebust@netapp.com>

    commit a6f951ddbdfb7bd87d31a44f61abe202ed6ce57f upstream.

    In nfs4_proc_getlk(), when some error causes a retry of the call to
    _nfs4_proc_getlk(), we can end up with Oopses of the form

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000134
    IP: [<ffffffff8165270e>] _raw_spin_lock+0xe/0x30
    <snip>
    Call Trace:
    [<ffffffff812f287d>] _atomic_dec_and_lock+0x4d/0x70
    [<ffffffffa053c4f2>] nfs4_put_lock_state+0x32/0xb0 [nfsv4]
    [<ffffffffa053c585>] nfs4_fl_release_lock+0x15/0x20 [nfsv4]
    [<ffffffffa0522c06>] _nfs4_proc_getlk.isra.40+0x146/0x170 [nfsv4]
    [<ffffffffa052ad99>] nfs4_proc_lock+0x399/0x5a0 [nfsv4]

    The problem is that we don't clear the request->fl_ops after the first
    try and so when we retry, nfs4_set_lock_state() exits early without
    setting the lock stateid.
    Regression introduced by commit 70cc6487a4e08b8698c0e2ec935fb48d10490162
    (locks: make ->lock release private data before returning in GETLK case)

    Reported-by: Weston Andros Adamson <dros@netapp.com>
    Reported-by: Jorge Mora <mora@netapp.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    fs/nfs/nfs4proc.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/fs/nfs/nfs4proc.c
    +++ b/fs/nfs/nfs4proc.c
    @@ -5106,6 +5106,7 @@ static int _nfs4_proc_getlk(struct nfs4_
    status = 0;
    }
    request->fl_ops->fl_release_private(request);
    + request->fl_ops = NULL;
    out:
    return status;
    }



    \
     
     \ /
      Last update: 2013-11-27 04:41    [W:4.212 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site