[Bug 259071] Read past EoF in NFS client and fusefs

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071

--- Comment #15 from commit-hook@FreeBSD.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=00ec7c6ab526e0a8b10f57c578f423d647c4d93b

commit 00ec7c6ab526e0a8b10f57c578f423d647c4d93b
Author:     Rick Macklem <rmacklem@FreeBSD.org>
AuthorDate: 2021-10-30 23:35:02 +0000
Commit:     Rick Macklem <rmacklem@FreeBSD.org>
CommitDate: 2021-11-14 02:52:26 +0000

    nfscl: Fix race between Lookup and Setattr of size

    PR#259071 provides a test program that fails for the NFS client.
    Testing with it, there appears to be a race between Lookup
    and VOPs like Setattr-of-size, where Lookup ends up loading
    stale attributes (including what might be the wrong file size)
    into the NFS vnode's attribute cache.

    The race occurs when the modifying VOP (which holds a lock
    on the vnode), blocks the acquisition of the vnode in Lookup,
    after the RPC (with now potentially stale attributes).

    Here's what seems to happen:
    Child                                Parent

    does stat(), which does
    VOP_LOOKUP(), doing the Lookup
    RPC with the directory vnode
    locked, acquiring file attributes
    valid at this point in time

    blocks waiting for locked file       does ftruncate(), which
    vnode                                does VOP_SETATTR() of Size,
                                         changing the file's size
                                         while holding an exclusive
                                         lock on the file's vnode
                                         releases the vnode lock
    acquires file vnode and fills in
    now stale attributes including
    the old wrong Size
                                         does a read() which returns
                                         wrong data size

    This patch fixes the problem by saving a timestamp in the NFS vnode
    in the VOPs that modify the file (Setattr-of-size, Allocate).
    Then lookup/readdirplus compares that timestamp with the time just
    before starting the RPC after it has acquired the file's vnode.
    If the modifying RPC occurred during the Lookup, the attributes
    in the RPC reply are discarded, since they might be stale.

    With this patch the test program works as expected.

    Note that the test program does not fail on a July stable/12,
    although this race is in the NFS client code.  I suspect a
    fairly recent change to the name caching code exposed this
    bug.

    PR:     259071

    (cherry picked from commit 2be417843a04f25e631e99d5188eb2652b13d80d)

 sys/fs/nfsclient/nfs_clrpcops.c | 29 +++++++++++++--
 sys/fs/nfsclient/nfs_clvnops.c  | 78 +++++++++++++++++++++++++++++++++++++----
 sys/fs/nfsclient/nfsnode.h      |  1 +
 3 files changed, 99 insertions(+), 9 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.