commit 928bb8c418b5f9e96dbccc8d7eafb6635ae81548
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Tue May 6 16:22:34 2008 -0700

    Linux 2.6.24.7

commit 0bbbae3bfd732f6c4d6b2a67121d77bf6b1c7f70
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Tue May 6 13:58:34 2008 -0400

    fix SMP ordering hole in fcntl_setlk() (CVE-2008-1669)
    
    commit 0b2bac2f1ea0d33a3621b27ca68b9ae760fca2e9 upstream.
    
    fcntl_setlk()/close() race prevention has a subtle hole - we need to
    make sure that if we *do* have an fcntl/close race on SMP box, the
    access to descriptor table and inode->i_flock won't get reordered.
    
    As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs.
    STORE descriptor table entry, LOAD inode->i_flock with not a single
    lock in common on both sides.  We do have BKL around the first STORE,
    but check in locks_remove_posix() is outside of BKL and for a good
    reason - we don't want BKL on common path of close(2).
    
    Solution is to hold ->file_lock around fcheck() in there; that orders
    us wrt removal from descriptor table that preceded locks_remove_posix()
    on close path and we either come first (in which case eviction will be
    handled by the close side) or we'll see the effect of close and do
    eviction ourselves.  Note that even though it's read-only access,
    we do need ->file_lock here - rcu_read_lock() won't be enough to
    order the things.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>